Compliance Compass: EU Regulations for Software, SaaS, and Cloud Hosting

TL;DR

• The EU has established a coherent framework with GDPR, NIS‑2, DORA, CRA, Data Act, and the Cloud Sovereignty Framework, systematically enhancing data protection, cyber resilience, digital sovereignty, and interoperability.
• For operators of software, SaaS, and cloud hosting, this means clear requirements for security-by-design, data processing, exit capability, third-party risks, and governance – but also reusable components that address many obligations simultaneously.
• The common goals of these regulations are: protection of personal and business-critical data, resilience against cyber incidents, reduction of vendor lock-in, and a sovereign European technology landscape.
• A strategically sensible approach is an integrated one: a clean ISMS, cloud-native architecture, documented processes, and transparent supply chains can cover large parts of the requirements of all six regulations in parallel.
• ayedo supports organizations in translating these regulations into sustainable architecture, platform, and process decisions, thus using compliance as a structured competitive advantage – from analysis to the operated platform.

Why a Compliance Compass is Necessary

The European regulatory landscape has become significantly denser in recent years. This is no coincidence but an expression of a clear political goal: Europe wants to be not just a consumer but an independent player in the digital space. This includes reliable data protection, robust infrastructures, fair competition conditions, and a minimum level of technological independence.

For you as a responsible person for software, SaaS, or cloud hosting, this means: Compliance is no longer just a topic for legal departments. Architecture, operating models, supplier selection, and product strategy are directly affected.

The good news: The six central regulations are not an unmanageable patchwork. Many requirements interlock and can be addressed with a consistent technical and organizational approach. This is where a conceptual “Compliance Compass” helps.

Overview of the Six Central EU Regulations

1. GDPR – General Data Protection Regulation

The GDPR has been applicable since 25.05.2018 and forms the basis of almost all other EU regulations in the digital space. It addresses:

• Protection of personal data and data subject rights
• Lawfulness and transparency of processing
• “Privacy by Design and Default”
• Security of processing (Art. 32), including technical and organizational measures
• Notification obligations in case of data breaches

Practical implications for software and SaaS operators:

• Architecture and data models must consider data protection principles (data minimization, purpose limitation, deletion concepts).
• Logging, monitoring, and backups must be designed to enhance security without violating data protection.
• Hosting decisions – especially with non-European hyperscalers – must be legally robust in terms of international data transfers.

GDPR is thus the foundation on which NIS‑2, DORA, CRA, Data Act, and the Cloud Sovereignty Framework build.

2. NIS‑2 – Network and Information Security

The NIS‑2 directive came into force on 16.01.2023 and must be transposed into national law by 17.10.2024. It targets operators of essential and important entities in 18 sectors (e.g., energy, health, digital infrastructure, cloud computing).

Core requirements:

• Risk management and security concepts for network and information systems
• Incident detection, reporting, and response
• Business continuity and disaster recovery
• Management responsibility and liability
• Supply chain security, including ICT service providers and cloud providers

For cloud and SaaS operators, this means two things: They may fall directly under NIS‑2 or be factually obligated by their customers as critical service providers. In both cases, demonstrable processes, metrics, and technical protective measures are required.

3. DORA – Digital Operational Resilience Act

The Digital Operational Resilience Act (DORA) has been in force since 16.01.2023 and will apply directly from 17.01.2025. It affects financial institutions (banks, insurers, payment service providers, etc.) and their ICT service providers.

DORA builds on NIS‑2 but goes significantly further in the financial sector:

• ICT risk management with clear responsibilities
• Structured incident management including reporting to supervisory authorities
• Regular resilience tests (e.g., Threat-Led Penetration Testing)
• Strict requirements for outsourcing and third-party management
• Contractual and governance requirements for cloud providers and SaaS providers

If you provide services for financial companies, DORA will shape your architecture and operational decisions – even if you are not directly regulated. Multi-region strategies, exit concepts, and testable emergency processes become hard requirements, not “best practices.”

4. CRA – Cyber Resilience Act

The Cyber Resilience Act (CRA) came into force in spring 2024. After a transition period of approximately 36 months, it will be applicable from 2027. It targets manufacturers and providers of connected software and hardware products.

Key elements:

• Security by Design and Default throughout the entire product lifecycle
• Documentation obligations and security baselines depending on criticality
• Mandatory vulnerability management processes and Coordinated Vulnerability Disclosure
• Provision of security updates over defined periods
• Requirements for Software Bill of Materials (SBOM) for many product classes

For software and SaaS providers, this means: Security requirements are no longer just contractual “goodwill” but legally anchored product features. Build pipelines, release processes, and dependency management must be aligned accordingly.

5. Data Act – Data Portability and Interoperability

The Data Act came into force on 11.01.2024 and applies from 12.09.2025. It pursues two goals:

• More access to usage data from connected products and services
• Reduction of vendor lock-in, especially in the cloud and SaaS area

Relevant requirements for cloud and SaaS operators:

• Transparent data access and portability rights for customers
• Obligation to support switching between cloud services with functional equivalence
• Requirements for open and documented interfaces
• Limitation or gradual reduction of exit fees

Thus, exit capability – the ability to move an application and its data to another environment – becomes a regulated feature. Architectural decisions regarding data formats, API design, multi-tenancy, and automation are directly affected.

6. Cloud Sovereignty Framework

The EU Commission’s Cloud Sovereignty Framework is not a law but a procurement framework that has been used and further developed since 2022. It evaluates cloud services along several sovereignty goals (SOV-1 to SOV-8), e.g.:

• Data sovereignty and GDPR compliance
• Operational sovereignty, including exit capability and reversibility
• Protection against extraterritorial access by foreign jurisdictions
• Security and compliance maturity, among others, in light of NIS‑2 and DORA

Public clients, but increasingly also regulated companies, use this framework to select suitable providers and operating models. For operators of platforms and SaaS solutions, it becomes a strategic sales argument to demonstrably meet the criteria of the Cloud Sovereignty Framework.

Common Goals: Sovereignty, Security, Interoperability

Across all six regulations, three guiding principles can be identified that reinforce each other.

Digital and Data Sovereignty

• GDPR secures the informational self-determination of individuals.
• The Data Act strengthens the sovereignty of companies over “their” data and usage information.
• The Cloud Sovereignty Framework addresses the sovereignty of European institutions against non-European infrastructures.

For your architecture, this means: You should consciously decide where data is stored, how it is processed, and how you limit dependencies on individual providers. Multi-cloud or “dual-vendor” strategies, standardized interfaces, and clear data classification become an important part of governance.

Security and Operational Resilience

• NIS‑2 and DORA focus on the organizational and technical resilience of infrastructures and services.
• The Cyber Resilience Act shifts security requirements deeper into product design and the development process.
• The GDPR explicitly anchors security requirements in Art. 32 (“Security of processing”).

The common picture: Security is no longer an add-on but a cross-cutting requirement across design, development, operation, and supply chain. For you, this means:

• ISMS and risk management are no longer optional but a central framework.
• Observability, structured incident response, and tested recovery scenarios are core elements of the architecture.
• Supplier and third-party management becomes a continuous process, not an annual questionnaire exercise.

Interoperability and Reduction of Lock-in

• The Data Act explicitly demands switching possibilities and functional equivalence when changing providers.
• The CRA requires that security properties are clearly documented and verifiable – which promotes standardized interfaces and formats.
• The Cloud Sovereignty Framework privileges providers who can demonstrate interoperability, openness, and portability.

The result is a clear trend towards open standards, transparent APIs, and portable applications. For cloud-native software, this is a great opportunity: Those who focus on containerization, open protocols, and standardized platforms in design are automatically better prepared for these requirements.

How the Pieces Fit Together

Instead of seeing six separate construction sites, it is worthwhile to leverage the overlaps.

GDPR as a Foundation

The GDPR provides the basis with Privacy by Design, data minimization, and security requirements:

• Data classification, deletion concepts, and access controls contribute simultaneously to NIS‑2, DORA, and cloud sovereignty.
• Transparent processing and documented legal bases facilitate compliance with audit and reporting obligations in other regulations.

Those who are well-positioned here have already completed a significant part of the “homework” for further regulations.

NIS‑2 and DORA: Resilience at Organizational and Sector Level

NIS‑2 and DORA both demand:

• a structured ICT risk management,
• clear management responsibilities,
• incident reporting and response processes
• and a minimum level of testing and documentation.

The difference: DORA sharpens these requirements for the financial sector and explicitly includes ICT service providers. For you, it may be sensible to take the stricter DORA requirements as a reference – even if you are not in the financial sector. This creates a future-proof standard that NIS‑2 aligns with.