Cloud Computing 2025 Comparisons

Data Privacy Regulations Applicable to Germany

The German legal framework governing data protection is shaped by EU regulations, including the General Data Protection Regulation (EU 2016/679) (GDPR). It applies directly in all EU member states (without requiring national implementing legislation).

In addition, Germany has adopted the Federal Data Protection Act (Bundesdatenschutzgesetz; BDSG), which governs issues that the GDPR does not directly regulate. The guiding principle of the GDPR and BDSG is that personal data processing is prohibited unless authorised by consent or legislation.

Furthermore, there is sector-specific data privacy legislation – eg, for healthcare – as laid down in Section 393 of Social Code Book (Sozialgesetzbuch, or SGB) V, establishing detailed requirements for using cloud computing in the statutory healthcare system.

Meaning of Personal Data and Special Categories

The GDPR distinguishes between personal data and “special categories of personal data”. Personal data is any information relating to an identified or identifiable natural person (data subject) (Article 4(1), GDPR). Special categories of personal data (Article 9(1), GDPR) include:

• racial or ethnic origin;
• political opinions;
• religious and philosophical beliefs;
• trade union membership;
• health data;
• genetic and biometric data; and
• information about sex life or sexual orientation.

Requirements for Processing Personal Data in the Cloud

The GDPR applies to the processing of personal data wholly or partly by automated means (Article 2(1), GDPR). Cloud computing typically involves the automated processing of personal data (eg, employee or customer data).

The right to process personal data requires either the consent of the individual data subject or one of the statutory permissions, particularly under Articles 6 and 9 of the GDPR. Given their sensitivity, the GDPR imposes stricter conditions for processing the aforementioned special personal data categories than for ordinary personal data. This is especially true in cases in which no explicit consent from the data subject is given.

Service providers must comply with strict rules to handle personal data and comply with data protection legislation. In a cloud computing context, the cloud computing provider usually processes a large amount of customer data, which typically includes personal data. This means that the customer and the provider must enter into a data processing agreement (Auftragsverarbeitungsvertrag) (Article 28 GDPR). For detailed information on this agreement, see 4.3 Data Processing Agreements and the Cloud.

The GDPR does not include data localisation requirements. Instead, it allows the storage and processing of data within the European Economic Area (EEA) and regulates the transfer of data to third countries (Articles 44–55, GDPR). Contracts with cloud computing providers often include data localisation requirements, such as an obligation for the provider to only process data within the EEA.

Specific requirements apply to data transfers outside the EEA. The GDPR permits personal data transfers outside the EEA in particular if:

• A European Commission decision determines that the recipient country provides an adequate level of protection (Article 45(1), GDPR); or
• the controller or processor provides appropriate safeguards, and data subjects can enforce their legal rights and have effective legal remedies (Article 46, GDPR) – the parties can provide appropriate safeguards by, among other means, adopting standard contractual clauses (SCCs) approved by the European Commission or by a supervisory authority with subsequent approval by the European Commission.

Transfer of data to the USA can be based on the EU-US Data Privacy Framework, signed by the EU and the USA in 2022 and implemented through an EU adequacy decision in 2023.

Under the GDPR, both cloud computing providers and customers bear direct responsibility for compliance. Article 83 of the GDPR imposes administrative fines of up to EUR20 million or 4% of global annual turnover (whichever is higher) for severe infringements, and up to EUR10 million or 2% of global annual turnover for lesser ones. These fines apply equally to both roles, though customers – as “data controllers” – face broader liability due to their overarching duties.

Article 82 of the GDPR further allows data subjects to claim compensation for material or non-material damage directly from either responsible party, with customers being jointly and severally liable with cloud computing providers for breaches (Article 82 (4)–(5), GDPR).

Sector-specific penalties exclusively for cloud computing providers regarding data privacy do not exist, however.

Within the GDPR, Article 32 GDPR lays down an obligation to take data security measures based on risk.

Under Article 32 GDPR, both the controller and the processor must implement appropriate technical and organisational measures, taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing, calibrated to the risk to individuals’ rights and freedoms. The regulation offers the following non-exhaustive baseline:

• pseudonymisation and encryption;
• ensuring the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
• the ability to restore availability and access to personal data in a timely manner after incidents; and
• a process for regularly testing and evaluating security measures.

Risk assessment should explicitly consider threats such as accidental or unlawful destruction, loss, alteration and unauthorised disclosure/access. In cloud settings, customers (controllers) and cloud computing providers (processors) must each meet Article 32’s risk-based standards and ensure staff process data only under proper instructions and authority controls. Practically, this typically means combining organisational measures (policies, roles, training) with technical controls (strong authentication, network and server hardening, secure communications, vulnerability handling) and life cycle safeguards (backup, retention and erasure processes).

NIS2 Security Obligations

Mid-sized and large businesses in specific sectors must also take note of the NIS2 Directive (Directive (EU) 2022/2555). NIS2 moves cybersecurity from the server room to the boardroom, with obligations that apply both to cloud computing providers and their customers.

NIS2 sets a horizontal EU baseline for medium and large entities across many sectors, introducing “essential” and “important” classifications, with stronger supervision for such entities. Germany’s implementation act (NIS2UmsuCG) is pending; the draft significantly enlarges the regulated perimeter beyond legacy cybersecurity legislation such as the Act on the Federal Office for Information Security (the “BSI Act”; BSI-Gesetz, or BSIG), which mainly focused on operators of critical infrastructure. However, the Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik; BSI) is also foreseen as the competent authority to supervise companies’ compliance with the NIS2 Directive.

Regulated sectors under NIS2 (Article 3, Annex I and II, NIS2 Directive) include:

• energy;
• transport;
• banking;
• financial market infrastructures;
• health;
• drinking water and waste water;
• digital infrastructure;
• information and communications technology (ICT) service management (B2B);
• postal and courier services;
• waste management;
• manufacture, production and distribution of chemicals;
• production, processing and distribution of food;
• manufacturing;
• digital providers; and
• research.

According to Annex I, Nr 8, cloud computing service providers are specifically targeted by the NIS2 Directive. In Article 6(30) of the NIS2 Directive, they are defined as: “a digital service that enables on-demand administration and broad remote access to a scalable and elastic pool of shareable computing resources, including where such resources are distributed across several locations”. Thus, most if not all cloud computing service providers fall under the scope of the NIS2 Directive.

Businesses within the scope of NIS2 (Article 21(2), NIS2 Directive) are obligated to implement risk-based, state-of-the art information security measures, including at least:

• policies on risk analysis and information system security;
• incident handling;
• business continuity, such as backup management and disaster recovery, and crisis management;
• supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;
• security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;
• policies and procedures to assess the effectiveness of cybersecurity risk management measures;
• basic cyber hygiene practices and cybersecurity training;
• policies and procedures regarding the use of cryptography and, where appropriate, encryption;
• human resources security, access control policies and asset management; and
• the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems, where appropriate.

The obligation to implement supply chain security measures may lead to customers requesting further contractual cybersecurity obligations regarding service contracts with cloud service providers. The same goes for cloud service providers in regard to their subcontractors – eg, when outsourcing the physical management of server infrastructure.

Additionally, the implementation of these measures is subject to executive approval and oversight of cybersecurity measures (management accountability).

C5 Attestation

In 2016, the BSI published the Cloud Computing Compliance Criteria Catalogue (C5), targeted at professional cloud computing providers. C5 specifies baseline security levels for cloud computing, covering issues such as security domains, data protection, compliance, incident management and transparency. While C5 is not binding (outside of the healthcare sector), cloud computing providers that implement C5 criteria may have a competitive advantage in winning contracts in competitive bids.

Under German legislation, data itself cannot be subject to proprietary rights. The law indirectly protects data through the protection of databases, which are defined as either:

• collections of works, data or other independent elements arranged in a systematic or methodical way and individually accessible by electronic or other means, and whose obtaining, verification or presentation requires a substantial qualitative or quantitative investment (Section 87a(1), Act on Copyright and Related Rights (Urheberrechtsgesetz; UrhG)); or
• collections of works, data or other independent elements that, by reason of the selection or arrangement of the elements, constitute the author’s own intellectual creation (Section 4(1), UrhG).

Additionally, Article 4(13) of the EU Data Act establishes a “license-before-use” rule, which is aimed at data generated by “connected products” – ie, items that obtain, generate or collect data and whose primary function is not the storing, processing or transmission of data on behalf of any party other than the user. Because the definition of a connected product expressly carves out equipment whose primary function is the storage, processing or transmission of data on behalf of another party – wording designed to exclude classical cloud computing services – the statutory obligation to obtain a user-based data licence for “readily available data” does not apply to standard infrastructure as a service (IaaS), platform as a service (PaaS) or software as a service (SaaS) offerings.

Because legislation does not typically offer sufficient protection, data ownership clauses are common in cloud computing agreements. These usually make the customer the owner of all rights contained in the stored data, subject to any rights of use that are necessary to provide the cloud computing services.

In essence, data portability under EU legislation aims to enable customers to switch between different cloud computing providers without hindrance. Rules on data portability are set out in the EU Data Act (EU 2023/2854), which fully entered into force on 12 September 2025. It generally applies to cloud computing providers, which fall under the definition of data processing providers according to Article 2(8) Data Act – and which direct their offerings to customers in the EU, regardless of the country in which their registered headquarter is located.

Under the Data Act, cloud computing providers must eliminate listed switching obstacles and support porting through the provision of extensive documentation. Written contracts must set out rights and duties for switching, including existing agreements. For more information on contracts see 4.4 Exit Strategies and Data Migration.

Technical baselines target interoperability. IaaS providers must take reasonable measures to achieve functional equivalence at the target; providers of other services must offer free, open interfaces with the information required for data transfer and interoperability, and implement future EU interoperability specifications or harmonised standards within 12 months of publication. Economic lock-ins are curtailed: cost-based switching fees are allowed only during the transition phase, with an outright ban on charging for the switching itself from 12 January 2027.

Non-compliance risks administrative fines under the forthcoming German implementation law, underscoring the need to update contracts and ensure technical readiness. In particular, cloud computing providers must consider contractual provisions protecting long-term contractual relationships with their customer, such as payment obligations for early exit due to switching provisions under the EU Data Act.

Under the GDPR, personal data must not be kept longer than necessary for the purposes for which it was collected (storage limitation, Article 5(1)(e)). Data subjects have the right to obtain erasure “without undue delay” where one of grounds under Article 17(1) applies, including that the data is no longer necessary, consent of the data subject has been withdrawn without another legal basis, an objection has been raised, processing is unlawful or a legal obligation to delete exists.

Customers remain accountable for overall compliance even when data is hosted by a cloud computing provider and should ensure that erasure is executed on strictly documented instructions. Where data has been made public, controllers must take reasonable, technology-appropriate steps to inform other controllers to erase links/copies (Article 17(2), GDPR).

Implementing erasure at scale in the cloud requires organisational and technical measures:

• define retention/deletion policies;
• record planned deletion timelines in a register (Article 30(1)(f), GDPR); and
• run periodic reviews to detect data that has reached its end of life.

Backups and archives must be managed separately: backups serve short- to mid-term availability, and it is often not possible to delete single records safely; archives are for long-term, legally required and/or permitted retention. To prevent the re-introduction of erased items during restore cycles, a “blacklist” or deletion log can be maintained (eg, hash or system log references) to automate re-deletion post restore. Contracts should contain termination clauses requiring the return of data in common machine-readable formats and secure deletion of all copies, including backups, with a certificate of destruction.

Cloud computing contracts by large providers are usually standardised and do not leave much room for negotiation for smaller customers. However, leading cloud computing providers have also responded to requirements – eg, in regulated sectors – by being more transparent, moving servers to the EEA and complying with established certifications to stay competitive (such as the C5 attestation).

Customers should therefore always review whether the contractual setup offered by cloud computing providers serves the purpose desired by the customer and complies with the regulatory requirements, bearing in mind that fundamental changes to the contract may not be possible. In case requirements and cloud offerings do not match, a more tailor-made solution may be required.

The Effect of the GDPR

Article 28(1) of the GDPR mandates that when data processing is carried out on behalf of the controller (customer), the controller shall use only processors (cloud computing providers) providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of the GDPR and ensure the protection of the rights of the data subject.

In practice, this obligation can have an impact on cloud computing contracts. The controller may demand that the processor agrees to extensive audit and documentation rights to gain an insight into the business organisation of the processor, as the obligation laid down in Article 28(1) is for the controller to fulfil.

The controller may also demand that the processor agrees to follow all obligations laid down in the GDPR and other applicable data protection laws. While this undertaking is declaratory in nature, it may enable the controller to claim damages from the processor, should data protection laws be infringed. It therefore serves as a warning to the processor.

In practice, most cloud computing providers have aligned their standard contracts with the requirements of the GDPR and the decisions of the supervisory authorities, and try to provide a contractual framework that is basically in line with most of these regulations.

According to Article 28(3) of the GDPR, the controller (customer) and processor (cloud computing provider) must enter into a data processing agreement – this must bind the cloud computing provider to certain contractual obligations as laid down in Article 28(3) of the GDPR, including but not limited to:

• processing the personal data only on documented instructions from the customer;
• ensuring that persons authorised to process the personal data have committed themselves to confidentiality;
• implementing technical and organisational measures to ensure an appropriate level of security;
• deleting or returning all personal data after the end of the provision of services; and
• allowing for and contributing to audits conducted by the customer.

Being the data controller, the customer remains legally responsible for the personal data and overall compliance and is subject to a wide range of obligations. In particular, the customer is responsible for fulfilling all obligations in regard to the rights of data subjects, as described in Chapter III of the GDPR. This includes the right to access to (Article 15, GDPR) and the right to erasure of (Article 17, GDPR) stored personal data.

A cloud computing contract should typically contain detailed provisions for termination and exit management.

Contractual Terms Mandated by the Data Act

The EU Data Act (Article 25(2)) mandates the inclusion of certain clauses in a contract between a provider of data processing services (cloud computing provider) and its customer, including but not limited to:

• clauses allowing the customer, upon request, to switch to a data processing service offered by a different provider of data processing services or to port all exportable data and digital assets to an on-premises ICT infrastructure;
• an obligation on the provider of data processing services to support the customer’s exit strategy in relation to the contracted services, including by providing all relevant information;
• a maximum notice period for initiation of the switching process, which shall not exceed two months;
• an exhaustive specification of categories of data and digital assets that can be ported during the switching process, including, at a minimum, all exportable data;
• a minimum period for data retrieval of at least 30 calendar days; and
• a clause guaranteeing full erasure of all exportable data and digital assets generated directly by the customer, or relating to the customer directly.

The contractual framework mandated by the Data Act sets a good baseline for a successful exit strategy. As many of the terms used in Article 25(2) of the Data Act are vague, however, the parties are required to specify them in greater detail. The parties may also wish to agree to further provisions, especially in terms of termination rights.

Termination Rights

A fixed-term contract cannot be terminated for convenience under German law, unless the contract expressly provides for this. If the customer wishes to have a contractual right to terminate the contract early, the termination may be subject to termination fees that cover initial investments that the cloud computing provider had to make. The same may apply if the customer utilises the switching provisions of the EU Data Act (see the foregoing) to force an early exit. From the cloud computing provider’s perspective, this could also trigger an early termination fee compensating the provider for its lost profits.

However, a party can terminate an agreement for good cause, such as a fundamental breach of contract (Section 543(1), Bürgerliches Gesetzbuch (BGB); the German Civil Code). A fundamental breach of contract occurs if either party fails to comply with essential contractual obligations. The contract can define and specify what constitutes a fundamental breach; for example:

• consecutive failures to make agreed payments;
• consecutive failures to meet agreed service levels; and/or
• consecutive failures to provide certain deliverables such as adaptions, configurations or implementation of software.

A cloud computing contract, which is qualified as a leasing contract under German law, can be terminated by both parties for good cause (Section 543(1), sentence 1, BGB). There is good cause if, having considered all the circumstances of the specific case and having weighed the interests of both parties against each other, the terminating party cannot reasonably be required to continue the contractual relationship until the work is completed, until the agreed end or until the end of a notice period. While the contract cannot exclude this termination right, one must note that the hurdles set up in Germany to achieve “good cause” to terminate are very high.

Section 543(2), sentence 1 of the BGB clarifies the meaning of good cause by offering some illustrative examples:

• failure by the lessor to grant the lessee the contractually agreed use of the leased object, in whole or in part, in due time, or subsequently depriving the lessee of such use;
• material infringement of the lessor’s rights by the lessee by gravely endangering the leased object through neglect of the diligence owed, or by unauthorisedly transferring it to a third party; and
• the lessee is in default regarding rent payments for two consecutive due dates, and/or regarding payment of rent in an amount equal to at least two months’ rent.

As already stated, the contract can further define the scope of termination rights.

Generally, the law requires the terminating party to give prior notice and a reasonable grace period to remedy the cause for termination. A cloud computing agreement often elaborates on this process in more detail (for example, by specifying the applicable timelines or escalation mechanisms). However, in severe cases, or when it is not possible to remedy the cause for termination, German law allows for a termination without prior notice.

Reporting Requirements Under the GDPR

Under the GDPR, a “personal data breach” is any security incident leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to personal data (Article 4(12), GDPR). A data breach must be reported unless it is unlikely to result in a risk to individuals’ rights and freedoms (Article 33(3), GDPR).

Minimum contents include:

• a description of the nature of the breach (with categories/approximate numbers of data subjects and records);
• contact details of the data protection officer or other contact point;
• likely consequences of the personal data breach; and
• measures taken or proposed to be taken by the controller to address the personal data breach.

Reporting Requirements Under the NIS2 Directive

The NIS2 Directive requires member states to create a legal framework that makes sure that businesses falling under the scope of NIS2 report significant security incidents to their national authority and/or computer security incident response team (CSIRT).

Generally, a “significant security incident” is one that causes (or may cause) severe operational disruption or financial loss for the entity, or material and immaterial harm to other persons; entities must also promptly communicate mitigation measures to service recipients facing a significant cyber threat and inform them if service delivery may be impaired.

In October 2024, the Commission adopted the Implementation Act (EU) 2024/2690, which clarifies when an incident is deemed significant in regard to digital infrastructure entities, including cloud computing providers.

According to Article 3(1) of (EU) 2024/2690, an incident affecting a digital infrastructure entity is deemed to be significant if:

• it has caused or is capable of causing direct financial loss for the relevant entity that exceeds EUR500,000 or 5% of the relevant entity’s total annual turnover in the preceding financial year, whichever is lower;
• it has caused or is capable of causing the exfiltration of trade secrets, as set out in Article 2, point (1), of Directive (EU) 2016/943, of the relevant entity;
• it has caused or is capable of causing the death of a natural person;
• it has caused or is capable of causing considerable damage to a natural person’s health; or
• successful, suspectedly malicious and unauthorised access to network and information systems capable of causing severe operational disruption has occurred.

For cloud computing providers specifically, an incident is also deemed significant if any of the following applies (Article 7, (EU) 2024/2690):

• a cloud computing service is completely unavailable for more than 30 minutes;
• the availability of a provider's cloud computing service is limited for more than 5% or more than 1 million of the cloud computing service’s users in the Union, whichever number is smaller, for more than one hour;
• the integrity, confidentiality or authenticity of stored, transmitted or processed data related to the provision of a cloud computing service is compromised as a result of a suspectedly malicious action; or
• the integrity, confidentiality or authenticity of stored, transmitted or processed data related to the provision of a cloud computing service is compromised, having an impact on more than 5% or more than 1 million of that cloud computing service’s users in the Union, whichever number is smaller.

What to Expect in Regard to the GDPR

Personal data breaches under the GDPR can have major legal consequences if not managed appropriately.

Generally, controllers must maintain an internal breach log documenting facts, effects and remedial steps (Article 33(5), GDPR). Processors (cloud computing providers) must notify the controller without undue delay upon becoming aware of a breach (Article 33(2), GDPR).

A defensible investigation begins with immediate containment (eg, isolating affected systems), evidence preservation (forensic logs, chain of custody), and a risk assessment focused on the likelihood and severity of harm to data subjects; this assessment drives both the authority notification threshold of Article 33 of the GDPR and any obligation to inform data subjects according to Article 34 of the GDPR.

Supervisory practice emphasises speed and completeness: to avoid fines, there must be quick reactions and adequate information flow. Internally, organisations should assign clear responsibilities, escalate promptly to legal and management, and ensure full information transmission with rapid updates as the situation evolves.

Remediation and recovery are anchored in Article 32 of the GDPR: controllers and processors must implement appropriate technical and organisational measures (as described in the foregoing). The fact that there has been a data breach implies that current measures are insufficient, calling upon the parties to re-evaluate and strengthen the measures taken.

Strong encryption can reduce notification burdens on data subjects where it renders data unintelligible to unauthorised persons (Article 34(3)(a), GDPR). Practically, remediation spans from verified restorations from clean backups, vulnerability handling and patching, and access governance updates to documented post-incident reviews.

Non-compliance risk is twofold:

• administrative fines – breaches can attract fines of up to EUR10 million or 2% of global annual turnover; and
• where failures also affect core data protection principles, authorities may even escalate to the higher tier (up to EUR20 million or 4% of global annual turnover).

Authorities assess factors such as nature, gravity and duration, prior infringements, co-operation and remedial actions. In addition, behaviour in the proceeding and co-operation can materially influence the outcome. Operational discipline and good-faith co-operation mitigate enforcement exposure when incidents occur.

Private claims are to be expected as well: data subjects may seek compensation for material or non-material damage under Article 82 of the GDPR, and breach communications often trigger damage claims. Of course, reputational damage due to press coverage of major incidents may cause further harm to companies and their business prospects.

How to Handle Incidents Under NIS2

Under NIS2, well-organised incident handling is a clear requirement for cloud computing providers: the Commission’s Implementing Regulation (EU) 2024/2690 translates the vague Article 21(2) requirements into concrete processes for in-scope entities.

According to Article 21(2)(b) of the NIS2 Directive (Article 2(1), Annex (EU) 2024/2690), cloud computing providers must have a documented incident-handling process that assigns roles and responsibilities and covers timely detection, analysis, containment/response, recovery, business continuity, documentation and reporting. As soon as a security incident has been detected, said incident-handling process should be implemented. Cloud computing providers also have to monitor networks/systems and keep logs so events can be detected, triaged and correlated. When remedying security incidents, those logs may help reconstruct the incident.

To ensure business continuity, activation of the business continuity plan is required. It must define scope, roles, contacts, activation criteria, recovery sequencing and objectives, resources and return-to-normal procedures.

Restoration from clean backups is required. The backup plan must ensure that there are complete/accurate copies, which should also be stored offline and segregated. Integrity checks and restoration tests must be performed regularly to be ready for incidents.

A formal post-incident review has to be performed as well, to determine the root cause, document lessons learned and feed improvements into security policies, risk treatment, incident detection and the testing regimen.

Management should receive regular compliance reports and oversee remediation to ensure effectiveness. Independent reviews and compliance monitoring should be implemented after major incidents to ensure that controls remain effective and improvements have been implemented.

Under the GDPR

After becoming aware of a data breach, the controller (usually the customer) must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours; as mentioned in the foregoing, notification is not required if the breach is unlikely to result in a risk to the rights and freedom of natural persons (Article 33(1), GDPR). For notifications taking longer than 72 hours, the delay must be justified. The 72-hour timer starts when the controller becomes aware of a breach – ie, when it can establish with sufficient certainty that a personal data breach occurred after an initial assessment.

Processors (usually the cloud computing provider) do not have to notify the authority; instead, they must inform the controller of any personal data breach without undue delay so the controller can meet its obligations.

Where the breach is likely to result in a high risk to individual data subjects, the controller must also communicate the breach to affected data subjects (Article 34(1), GDPR). Failures to notify the authority or data subjects can attract administrative fines under Article 83(4) of the GDPR.

The competent supervisory authority in Germany is usually the state data protection authority (Landesdatenschutzbehörde) in the state where the controller is located.

Under NIS2

Under the NIS2 Directive, EU member states have to ensure that both essential and important entities notify the competent authority when a significant incident occurs (Article 23(1), NIS2). Cloud computing providers of medium size are in scope of NIS2, as mentioned in the foregoing. The same may apply to their customers, depending on the sector.

NIS2 foresees an early notification obligation without undue delay, and at the latest within 24 hours after becoming aware of the incident, indicating whether an unlawful/malicious cause and/or potential cross-border impact is suspected.

After 72 hours, another notification has to provide updated information as well as an initial assessment of the incident, including its severity and impact. One month after that, a final report has to be provided, including the following:

• a detailed description of the incident, including its severity and impact;
• the type of threat or likely root cause of the incident;
• applied and ongoing mitigation measures; and
• where applicable, the cross-border impact of the incident.

Failure to comply with reporting obligations under NIS2 can result in administrative fines as well.

Under Germany’s draft law on NIS2 implementation, the Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) is designated as the competent authority for essential and important entities.

As already mentioned in 1.2 Data Privacy and Cross-Border Transfers, the GDPR allows the storage and processing of data within the EEA and regulates the transfer of data to third countries (Articles 44–55, GDPR (Chapter V)).

To limit compliance requirements and gain the trust of customers, many cloud computing providers have built data centres in the EU, so that additional Chapter V provisions do not need to be followed. However, for smaller providers and/or certain use cases that may be difficult, as data centres may require large investments.

According to the European Data Protection Board, a cross-border transfer occurs where, cumulatively:

• a controller or processor involved in the processing is subject to the GDPR;
• that entity transmits or otherwise makes personal data available to another controller or processor (the data importer); and
• the data importer is in a third country.

Therefore, when a customer engages a cloud computing provider in a third country, a transfer generally occurs. Onward transfers by the cloud computing provider from one third country to another, or within the third country, are also explicitly covered by Article 44 of the GDPR.

Compliance involves a two-stage analysis. In the first stage, transfers must comply with the provisions of the GDPR in addition to Chapter V: a lawful basis must exist (for example under Article 6 or 9, GDPR), and the requirements of Article 28 of the GDPR must be met. Note that transparency duties apply: data subjects must be informed under Article 13(1)(f) of the GDPR of any intended third-country transfers, the presence or absence of an adequacy decision and the safeguards relied on.

The GDPR does not purport to apply directly to cloud computing providers in third countries. Rather, customers in the EU are responsible first and foremost for ensuring compliant data exports. However, third-country cloud computing providers can be bound through Chapter V instruments and, contractually, via Article 28 terms if they act as processors.

In the second stage, the transfer instruments in Chapter V must be applied. When the recipient is outside the EU/EAA, the GDPR presumes, as a starting point, that the local level of protection is not adequate, but allows the establishment of an adequate level through the tools set out in Articles 45–47 of the GDPR.

Transfers on the basis of an adequacy decision (Article 45, GDPR) by the European Commission are the most straightforward: data may flow where the Commission has determined that the third country ensures an adequate level of protection. Such decisions are based on a multifactor assessment and are subject to periodic review at least every four years, and to ongoing monitoring. If an adequacy decision is repealed, controllers have to rely on a different safeguard.

The Commission has recognised adequacy for a number of countries, including the United Kingdom, the United States, Japan, South Korea and Switzerland. Cloud computing customers must always check the scope of any adequacy decision, which may be limited to certified recipients, as in the case of the EU-US Data Privacy Framework.

The requirements of the EU-US Data Privacy Framework deserve particular mention in the context of cloud computing practice. Under the framework, US companies have to annually commit to principles and obligations with the Department of Commerce, such as purpose limitation, data minimisation, storage limitation, data security and specific rules for onward disclosures. Only certified companies can receive data from the EEA under the adequacy decision.

If there is no adequacy decision by the European Commission for a third country, appropriate safeguards under Article 46 of the GDPR become relevant. Standard contractual clauses (SCCs) adopted by the Commission remain the most widely used safeguards in cloud computing contracts. The SCCs adopted in 2021 can be used without specific authorisation, provided the clauses are incorporated unaltered and the annexes are duly completed with the specifics of the processing and transfers. However, as required by Clause 14 of the SCCs, customers must assess whether the law and practices in the cloud computing provider’s jurisdiction would prevent compliance with the clauses; where doubts persist, supplementary measures must be agreed to.

Germany and the EU do not impose a blanket, cross-sector statutory data localisation regime. In practice, however, many German cloud computing contracts include EEA-only processing commits – eg, an obligation on the provider to process and store data only within the EEA.

The healthcare sector is the only sector where geographic limits strictly apply. Section 393 of SGB V mandates that, for cloud computing, processing location is restricted to countries within the EEA or where an adequacy decision applies.

Regimes in other sectors, such as the Digital Operational Resilience Act (EU 2022/2554; DORA) for financial entities, concentrate on risk management; however, storage within the EEA may be a part of compliant risk management. For more detailed information, see 7.1 Cloud Computing and Compliance/Audits.

Aside from what has already been mentioned, a core friction point in international data transfers is foreign disclosure or access orders.

The GDPR does not allow foreign public authority demands made to cloud computing providers running servers in the EU to serve as a self-standing legal basis for transfers. Article 48 of the GDPR mandates that any judgment or administrative decision of a third country that requires a controller or processor to disclose personal data may only be recognised or enforceable if it rests on an international agreement in force between the requesting state and the EU member state.

The problem with this requirement is illustrated best by disclosure demands under US law. Under the US CLOUD Act, US providers of electronic communications or remote computing services must disclose any data in their possession, custody or control to national authorities, irrespective of whether the data are stored in or outside the United States (18 U.S.C., Section 2713). While the Act offers a motion to quash under certain conditions – namely, where the request targets non-US persons and the disclosure would risk violating the law of a “qualifying foreign government”, defined as a state with which the US has concluded an “Executive Agreement” under 18 U.S.C. Section 2523 – this relief is limited, and absent such an agreement only narrow defences are available. At present, an Executive Agreement with the EU does not exist.

The European Data Protection Board and the European Data Protection Supervisor have addressed this tension. In their analysis, they concluded that a foreign transfer based on the US CLOUD Act is typically in conflict with the GDPR.

The Schrems II decision by the EU Court of Justice declared the former EU-US adequacy decision, the EU-US Privacy Shield, inadequate. Part of the court’s critique was the breadth of data collected, and the absence of effective redress for EU individuals against US national security access to personal data.

This issue was addressed by US Executive Order (EO) 14086 (“Enhancing Safeguards for United States Signals Intelligence Activities”), signed on 7 October 2022. First, EO 14086 introduced binding safeguards that limit access to what is necessary and proportionate to protect national security. Second, it enhances oversight of intelligence activities to ensure compliance with those limits. Third, it creates a two-layer redress mechanism available to any individual whose data has been transferred from the EEA: an investigation by a Civil Liberties Protection Officer within the US intelligence community, followed by the possibility to appeal to a newly established Data Protection Review Court composed of members from outside the US government, appointed on the basis of specific qualifications and protected against arbitrary removal.

According to another recent EU Court of Justice decision, the newer EU-US privacy framework now meets the standards laid down in the GDPR; the Court argued that the rights of data subjects are now adequately protected because of EO 14086.

At the same time, a realistic assessment must acknowledge the limits and open questions that persist on the US side; especially whether large-scale intelligence data collection has really been meaningfully limited by EO 14086. However, the aforementioned judgment provides a safe legal footing for the time being.

Amongst other things, like growing demand for security in times of geopolitical tension, this conflict of law has long catalysed customer and legislator focus on a concept called digital sovereignty. One important requirement in achieving digital sovereignty is that data hosted within a country’s borders is to be exclusively controlled by that nation’s legislation. This gives EEA-based cloud computing providers hosting sovereign data centres a significant competitive edge.

Germany has recognised the increasing risk that the use of the cloud can present for certain key sectors of the economy. Cloud computing keeps key sectors running, including finance, insurance and health. Therefore, there are heightened compliance requirements in those sectors.

Financial Sector

Banks, financial service providers and other entities in the financial sector are subject to specific regulatory provisions due to their importance to the economic and financial system. Regulations specifically address cloud computing, covering both:

• the decision on whether and how to outsource services; and
• the design, implementation and termination of agreements with service providers.

Financial institutions must ensure proper business organisation, which includes an obligation to implement, maintain and continuously develop effective risk management (Sections 25a and 25b, Banking Act (Kreditwesengesetz, or KWG). The aim of risk management is to recognise, assess and manage any risk to the financial institution as early as possible.

The banking and financial sector is supervised by:

• the Federal Financial Supervisory Authority (Bundesanstalt für Finanzdienstleistungsaufsicht; BaFin);
• the German Federal Bank (Deutsche Bundesbank); and
• the European Central Bank (ECB).

These authorities monitor compliance with regulatory requirements very strictly, including by auditing compliance with risk management obligations (Sections 25a and 25b, KWG) and the use of (electronic) data processing.

BaFin has issued the following circulars, which apply to institutions subject to the KWG:

• Circular 05/2023 (BA) – Minimum Requirements for Risk Management (MaRisk); and
• Circular 10/2017 (BA) – Supervisory Requirements for IT in Financial Institutions (Bankaufsichtliche Anforderungen an die IT, or BAIT – which will, however, be fully superseded by DORA (see the following) and repealed effective on 31 December 2026).

These circulars reflect BaFin’s interpretation of the KWG, and its implementation. Section 9 of MaRisk and Section 9 of BAIT contain guidance on outsourcing (including cloud computing), in particular on risk analysis and monitoring in the context of the business organisation. For example, an institution should:

• conduct a risk analysis and consider the result of the analysis throughout the outsourcing;
• consider not delegating management responsibility to the service provider; and
• manage the risk associated with the outsourcing, and monitor service providers and outsourced processes – for example, through key performance indicators (KPIs) or key risk indicators.

These circulars are not legally binding but constitute administrative standards for interpreting the legal requirements. In practice, financial institutions in Germany tend to adhere strictly to this guidance to avoid the risk that BaFin imposes supervisory measures. Therefore, regulatory clauses in cloud computing agreements are often heavily negotiated if the customer is part of a German regulated industry.

In February 2024, BaFin published guidance on outsourcing to cloud providers (the “BaFin Notice”), which reflects current supervisory practice and complements MaRisk and BAIT by providing guidelines on the drafting of outsourcing agreements. The notice covers essential requirements for IT outsourcing contracts, including the following.

• Contracts should not restrict the information and audit rights of the customer. In particular, common clauses in contracts drafted by cloud service providers that restrict audits to certain documents, reports and certifications are prohibited. Instead, physical audit access must be granted where required (Section III. 5.2, BaFin Notice).
• Any subcontractors should also comply with regulatory requirements. The cloud service provider must ensure that the entire outsourcing chain complies with regulatory requirements and guarantee equivalent information and audit rights (Section III. 5.7, BaFin Notice).

The BaFin Notice covers all types of cloud services, such as IaaS and SaaS. The BaFin Notice also includes guidance on the following.

• Organisational requirements.
• Governance.
• Secure application development and IT operations.
• Monitoring and controlling cloud service providers.
• Factors that financial institutions must consider when analysing and evaluating their outsourcing arrangements, including:
1. effects of insolvency;
2. risk of data access by foreign governments or states;
3. risk-mitigation measures;
4. internal guidelines; and
5. information and audit rights.

On top of this supervisory guidance, financial institutions and their cloud computing providers must focus on implementing the requirements of DORA. It harmonises the rules applicable to financial institutions and ICT third-party service providers in relation to digital operational resilience, ICT risks and cybersecurity. DORA has been directly applicable to all financial institutions in the EU since 17 January 2025.

To ensure continuity in financial services, DORA addresses the various risks caused by the increasing dependency of regulated institutions on external service providers for technology and outsourcing.

DORA covers:

• ICT risk management throughout the entire supply chain (Articles 5–16);
• ICT third-party risk management (Articles 28–30), containing minimum requirements for ICT service provider contracts;
• digital operational resilience testing (Articles 24–27);
• general requirements for ICT-related incidents, classification and reporting (Articles 17–23);
• information-sharing arrangements (Article 45); and
• the oversight of critical third-party providers (Articles 31–44).

DORA defines ICT services as “digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis, including hardware as a service and hardware services which includes the provision of technical support via software or firmware updates by the hardware provider, excluding traditional analogue telephone services” (Article 3(21), DORA).

DORA imposes stricter requirements for “critical and important functions”, which are defined as “a function, the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law” (Article 3(22), DORA). Cloud computing providers commonly fall under the scope of DORA, with stricter requirements applying depending on the service provided.

In practice, financial service institutions must particularly focus on Article 30 of DORA, which requires them to check all of their existing outsourcing and cloud computing contracts against the minimum contractual requirements of Article 30, and amend or supplement their contracts where applicable.

Insurance Sector

Insurers and reinsurers are also subject to specific supervision and the obligation to ensure proper business organisation in relation to outsourcing (including cloud computing), including data protection, confidentiality, continuity of operations, risk management, risk analysis, contract design and contract implementation.

Outsourcing agreements entered into by insurers and reinsurers must be in writing and clearly state certain minimum requirements, including the following (Section 32(2), Insurance Supervision Act (Versicherungsaufsichtsgesetz, or VAG); Article 274(3)–(5), Solvency II Delegated Regulation ((EU) 2015/35)):

• the duties and responsibilities of the parties; and
• the service provider’s commitment to comply with all applicable laws, regulatory requirements and guidelines, as well as with policies approved by the insurance or reinsurance undertaking, and to co-operate with the undertaking’s supervisory authority over the outsourced function or activities.

BaFin has also published the following guidance on the regulatory requirements applicable to insurance companies for an outsourcing.

• Circular 02/2017 (VA) - Minimum Requirements under Supervisory Law on the System of Governance of Insurance Undertakings (Mindestanforderungen an die Governance von Versicherungsunternehmen; MaGo), last updated on 14 October 2025, which provides guidance on the interpretation of the VAG. For example, MaGo explains the principle of proportionality, under which requirements must be fulfilled in a manner that is proportionate to the nature, scale and complexity of the risks inherent in an undertaking’s business activities. Insurance companies must determine their own risk profile and define appropriate implementation measures to manage risks. ICT outsourcing requires a risk analysis (Section 13.3, MaGo) and risk management or internal control systems, especially if the service provider is located outside the EEA (Section 13.2, MaGo). MaGO supplements the guidelines on systems of governance of the European Insurance and Occupational Pensions Authority (EIOPA).
• Supervisory Requirements for IT in Insurance Undertakings (Versicherungsaufsichtliche Anforderungen an die IT; VAIT). VAIT contains guidelines on the interpretation of the VAG regarding IT strategy, IT governance, the management of IT resources, information security management and information risk management.

DORA is applicable to insurers and reinsurers as well. Hence, the implementation of this act is currently the main focus of these organisations, including but not limited to the review and amendment of ICT provider contracts in accordance with Article 30 DORA.

Healthcare Sector

When engaging cloud computing services in the healthcare sector, compliance with Section 393 of SGB V must be verified. It authorises cloud use only where its prerequisites are fulfilled and applies across a wide set of healthcare actors (including statutory health insurers, contracted physicians/dentists/psychotherapists, hospitals, pharmacists, and aids and remedies suppliers) when they process health data in the cloud.

Key checks include:

• location and presence – the processing location must be in Germany, an EEA country, Switzerland or another country where an adequacy decision applies (such as the USA);
• confirming state-of-the-art technical and organisational measures, which vary depending on the healthcare actor using the cloud computing service; and
• provider assurance – obtain a current C5 attestation for the cloud systems/technology.