Data Privacy Regulations

The primary data privacy regulations applicable to cloud computing in Switzerland are the Federal Act on Data Protection (FADP) and its implementing ordinance, the Ordinance on Data Protection (DPO), both of which entered into force on 1 September 2023. Due to its extraterritorial scope, the EU General Data Protection Regulation (GDPR) may also apply to cloud computing in Switzerland, albeit this article is limited to Swiss law.

In Switzerland, there is no dedicated legislation governing cloud computing by private entities, with one exception: As of 1 April, 2025, the Information Security Act (ISA) requires Swiss cloud computing providers and operators to report cyber-attacks on their IT resources to the National Cyber Security Centre (NCSC) within 24 hours of becoming aware of the attack (Article 74a and 74b(1)(t) ISA). However, sector-specific legislation may impose special requirements for cloud computing (for example, in the banking, insurance, and health sectors). In addition, the secrecy provisions under Swiss law must be taken into account, as these restrict the use of cloud services and may require certain technical and organisational measures to be implemented. This is the case, for example, with professional secrecy, such as that of doctors and lawyers, and with banking secrecy.

Personal Data, Sensitive Personal Data and the Requirements for its Processing

As in the EU, Swiss data privacy regulations only apply to the processing of personal data. Under the FADP, personal data is broadly defined as any information relating to an identified or identifiable natural person (Article 5(a) FADP). In principle, the term is understood in the same way as under the GDPR. Examples include a natural person’s name, address and account credentials, but also their phone number, IP address and social security number. According to Article 5(c) FADP, the following types of personal data are considered sensitive:

• data relating to religious, philosophical, political or trade union-related views or activities;
• data relating to health, the private sphere or affiliation to a race or ethnicity;
• genetic data;
• biometric data that uniquely identifies a natural person;
• data relating to administrative and criminal proceedings or sanctions; and
• data relating to social assistance measures.

As there is no dedicated legislation governing cloud computing by private entities, the requirements for processing (sensitive) personal data in the cloud are the same as those outside of a cloud environment. For private entities, this means that the processing activities must comply with the data protection principles such as transparency, proportionality and data security (Article 6 and 8 FADP). Furthermore, data must not be processed against the express wishes of the data subjects and sensitive data must not be disclosed to third parties, ie, other controllers (Article 30(2) FADP). Breaching any of these principles means the processing infringes the data subject’s personality rights and is unlawful, unless justified by the data subject’s consent, a prevailing interest or the law (Article 31 FADP). In the case of sensitive personal data, any necessary consent must be given explicitly (Article 6(7)(a) FADP).

Obligations for Data Controllers and Processors

The cloud service provider usually acts as a processor for the customer as defined in Article 9 FADP. The customer can be the controller or a processor itself. In the cloud environment, there are no specific obligations for controllers and processors; instead, they must comply with the general obligations of their respective roles. As the processor, the cloud service provider may only (i) process the data in ways that the controller itself is permitted to do and (ii) assign processing to a third party with the controller’s prior approval. The main obligations of a processor include taking suitable technical and organisational measures (TOMs) for data security (Article 8 FADP) and notifying the controller of any breach of data security as quickly as possible (Article 24(3) FADP).

The main obligations of a processor include taking suitable technical and organisational measures (TOMs) for data security (Article 8 FADP) and notifying the controller of any breach of data security as quickly as possible (Article 24(3) FADP).

As the controller, the customer is responsible for ensuring that the data processing carried out by the cloud service provider on its behalf complies with data protection requirements (see above). Furthermore, the controller has to fulfil the following obligations.

• Concluding a data processing agreement (DPA): While the content of a DPA is only rudimentarily regulated in the FADP, these agreements often mirror GDPR standards in practice (Article 9 FADP). For more details, see 4.3 Data Processing Agreements and the Cloud.
• Duty to provide information and data subject rights: The controller must inform data subjects about its data processing activities, including those carried out on its behalf by a processor (Article 19-21 FADP). Additionally, the controller must fulfil the data subjects’ rights, such as the rights to access, rectification, and erasure (Article 25-29 and 32 FADP).
• Conducting a data protection impact assessment (DPIA): This is required if processing is likely to result in a high risk to the data subjects’ personality or fundamental rights. A high risk arises in particular if sensitive personal data is processed on a large scale or if the processing involves new technologies such as artificial intelligence (Article 22 FADP). Cloud computing should not be regarded as a new technology, and therefore, a DPIA is not required on this basis alone.
• Notifying the Swiss Federal Data Protection and Information Commissioner (FDPIC) of data security breaches: The controller must notify the FDPIC of any breach that is likely to lead to a high risk to the data subject’s personality or fundamental rights as quickly as possible. For more details, see 5. Data Breach Notification.

Both the controller and the processor must maintain records of their processing activities (Article 12 FADP) and, under certain conditions, they must issue regulations on automated processing and log their automated processing (Article 4-5 DPO). For more details, see 2.1 Data Security and the Cloud.

Under Swiss data privacy law, there are no specific rules for cross-border data transfers in the context of cloud computing. The general requirements for cross-border data transfers of personal data apply (Article 16-18 FADP).

In principle, Switzerland permits the transfer of personal data abroad only if the destination country guarantees an adequate level of data protection, as determined by the Swiss Federal Council (Article 16(1) FADP). If such an adequacy decision is not in place, personal data may only be transferred abroad if an appropriate level of data protection is guaranteed by additional safeguards – such as by a treaty under international law, standard data protection clauses or binding corporate rules (Article 16(2) FADP).

In exceptional cases, data may even be transferred abroad without additional safeguards. These exceptions include transfers with the data subject’s explicit consent, transfers that are directly connected with the conclusion or performance of a contract and transfers of data that the data subject has made generally accessible and has not explicitly prohibited processing (Article 17 FADP).

The requirements and rules regarding data transfers are described in greater detail in 6. International Data Transfers.

In principle, there are no specific penalties for non-compliance with data privacy regulations in the cloud – with one exception, which concerns the cloud computing providers’ and operators’ duty to report cyber-attacks on their IT resources to the NCSC (Article 74a and 74b(1)(t) ISA; see 1.1 Data Privacy and Cloud Computing and 5.1 Requirements to Report Data Breaches). As of 1 October 2025, if a cloud computing provider or operator fails to comply with this obligation and also fails to submit a report within an additional period set by the NCSC, a fine of up to CHF100,000 may be imposed (Article 74g-74h ISA).

Under the FADP, certain breaches of data protection obligations can result in criminal liability for individuals on condition that a data subject files a complaint. The maximum fine is CHF250,000, and fines are generally imposed on the person responsible for the violation. This includes individuals within private companies, such as directors, officers, and employees with independent decision-making power (Article 29 Criminal Code), provided they acted wilfully (Article 12 Criminal Code). If the responsible individual cannot be identified due to a lack of proper internal organisation, the company may be fined up to CHF50,000 (Article 64 FADP). The relevant breaches include (Article 60-61 FADP):

• failure to provide the required information to the data subjects;
• failure to comply with the right to access;
• transferring information to a recipient abroad in violation of transfer restrictions;
• disclosing personal data to a data processor in violation of a confidentiality obligation, or without ensuring adequate data security measures on the part of the processor; and
• failure to take the minimum security measures that may be set out in the DPO.

While the FDPIC cannot impose fines, it may initiate an investigation against controllers and processors (ex officio or upon notification by a data subject or other party) if there are sufficient indications that processing could violate the FADP (Article 49(1) FADP). If the FDPIC concludes that the FADP has been violated, it may order the processing to be fully or partially adjusted, suspended or terminated, and order that personal data be fully or partially deleted or destroyed (Article 51(1) FDPA). The FDPIC may also defer or prohibit disclosure abroad and order the controller and the processor to fulfil their respective obligations under the FADP, such as informing the data subjects about the processing, performing a DPIA or providing data subjects with access to their data.

Data Security Requirements

Swiss data protection law is principle-based. Controllers and processors must ensure a level of data security commensurate with the respective risks, protecting confidentiality, integrity, availability, and traceability. Rather than prescribing specific TOMs or certain technologies, the FADP and DPO expect controllers and processors to calibrate their measures to the data types, processing context and current technology. The only exceptions to this principle-based model are the obligations to issue regulations on automated processing and to maintain data processing logs. If private entities process large volumes of sensitive personal data or conduct high-risk profiling, they must:

• document their internal organisational structure, data processing and control procedures, and TOMs; and
• log the storage, alteration, reading, disclosure, deletion and destruction of the data (Article 4-5 DPO).

However, in the financial, health and other regulated industries, sector-specific regulations may require specific measures. For cloud-based services in the financial sector, for example, the following TOMs are among the measures that are required (depending on certain conditions) or considered best practice:

• access to customer data in unencrypted form only on a strict need-to-know and just-in-time basis;
• provision of a list of all persons with administrative rights to access, change or delete customer data;
• multi-factor authentication or equivalent for any access to customer data;
• encryption of all customer data at rest (data stored on a server) and in transit (data moving from one location to another; see also below);
• obligation to keep all data processing (including remote access) within Switzerland or at the locations of permitted sub-processors; and
• ISO/IEC 27001 certification and/or ISAE 3402 attestation.

Encryption in Transit and at Rest

Encryption of data in transit means using a secure communication protocol, for example, the TLS (Transport Layer Security) protocol. This is an encryption protocol that enables secure data exchange between the client (ie, an end device or user application) and the server. The use of TLS is visible to users – eg, by the padlock symbol that is then displayed in the address bar of most browsers.

Data at rest can be encrypted using either symmetric or asymmetric encryption. In symmetric encryption, the same key is used to encrypt and decrypt data. In asymmetric encryption, a pair of public and private keys is used: data encrypted with the public key can only be decrypted with the corresponding private key. In both cases, it is essential to select a suitable encryption method and, in particular, avoid using methods that have become obsolete over time. In January 2024, the FDPIC recommended in its guidelines on TOMs the following algorithms:

• for symmetric encryption, Advanced Encryption Standard (AES) with a key length of 128 or 256 bits; and
• for asymmetric encryption, ECIES-KEM (Elliptic Curve Integrated Encryption Scheme – Key Encapsulation Mechanism) or DLIES-KEM (Discrete Logarithm Integrated Encryption Scheme – Key Encapsulation Mechanism).

Access Control Measures

In addition to encryption, access control measures are essential in a cloud environment. Appropriate TOMs must be taken to ensure that:

• only authorised persons have access to the premises, infrastructure and systems in which personal data are processed; and
• authorised persons only have access to the personal data that they require to fulfil their tasks (Article 3(1) DPO).

While there are numerous possible measures, the following TOMs appear particularly relevant for cloud computing:

• authorisation – individual granting of access rights, role concepts for all involved systems and user authorisation management with regular reviews of authorisations;
• authentication – password-protected devices and systems, multi-factor authentication and secure session management with automatic logout after inactivity; and
• tenant separation – customer data is physically and/or logically separated by customer or project, eg, through separate domains or isolated cloud workspaces.

The handling of security accidents and breaches is further described in 5. Data Breach Notification.

Swiss law does not recognise “ownership” of personal data. The data subjects’ control arises from personality and data subject rights, while the controller’s control stems from contractual rights and obligations. Cloud agreements typically clarify that data ownership remains with the customer, not the cloud service provider. Furthermore, the corresponding DPA should permit the cloud service provider to process data only on the basis of documented instructions, require it to maintain strict confidentiality and prohibit any use of the data for its own purposes (eg, product development or training AI models).

In the cloud, data subjects retain all rights granted to them under the FADP, including the right to access, rectify and erase their data. Exercising these rights usually involves contacting the data controller – typically the customer – who must then co-ordinate with the cloud service provider, if necessary. When a data subject submits a request to the cloud service provider, the provider is obligated to forward this request to the customer, as stipulated by the DPA. Customers need to ensure that their cloud service provider has established processes and technical measures to efficiently handle such requests, including the extraction or deletion of data stored in the cloud. Furthermore, it is important to conclude contract terms that require cloud service providers to co-operate with the controller and assist them in fulfilling their obligations.

Data portability refers to the capacity to retrieve and transfer information seamlessly across different (cloud) service providers. In the context of cloud computing, data portability has two facets. Firstly, there is the portability necessary for customers to take their data with them when switching to another provider. Secondly, there is the right to portability under data protection law, to which data subjects are entitled under certain conditions.

For customers, achieving technical portability relies on the use of standardised data formats, application programming interfaces (APIs), and appropriate migration tools. To avoid vendor lock-in and enable orderly and efficient transitions between cloud environments, it is advisable to carry out strategic planning and agree on contract terms with the cloud service provider that explicitly address data portability and provide for migration assistance. For more details on data migration and respective assistance services, see 4.4 Exit Strategies and Data Migration.

Under Swiss law, data subjects benefit from a right to data portability for data they have provided to the controller, where automated processing is carried out with the consent of the data subject or in direct connection with a contract concluded between the data subject and the controller. Data subjects may request the controller to deliver the personal data in a conventional electronic format and, where feasible, without disproportionate effort, to transfer the data to another controller (Article 28 FADP). As controllers, customers must ensure that their cloud service provider and the respective services allow them to export the relevant data and assemble the responses to data portability requests within the necessary timeframe (in principle, 30 days; Article 18 and 22 DPO).

According to Article 6(4) FADP, data must be destroyed or anonymised as soon as it is no longer required for the purpose of processing (eg, in the case of agreements, usually for the duration of the agreement). However, data may be stored for a longer period if there is a legitimate interest in storing it (eg, to enforce legal claims, for archiving or to ensure IT security) or if the data is subject to retention obligations (eg, a ten-year retention period applies for accounting records). If further storage can no longer be justified, the data in question must be deleted from all storage media and, in principle, also from backups. In practice, however, it is accepted that data in backups is not deleted immediately but remains stored until the respective backup completes its retention cycle and is overwritten or deleted.

Data retention and deletion in the cloud are primarily governed by contractual agreements such as the cloud service agreement and the DPA, which define how long data is stored and when it must be deleted. Customers can often configure retention periods within the cloud platform, setting rules to retain or delete data automatically after a specified time. Many cloud service providers offer lifecycle management tools that enforce these schedules without manual intervention. When a customer terminates a service, providers usually commit to deleting data within a fixed timeframe; however, archived backups may be retained beyond that period for legal or security reasons.

Customers must conduct thorough due diligence when selecting a cloud service provider – most importantly, verify the provider’s ability to meet the relevant data protection and security requirements, particularly those set out in the FADP. To assess how data will be processed and what risks there are, it is necessary to have at least a basic understanding of the cloud services being procured and their underlying technology. Furthermore, the provider’s contractual framework, including the DPA, should be reviewed to ensure it includes clear roles and responsibilities, sufficient TOMs and effective remedies in case of breach. The DPA must at least cover the minimum legal requirements (see 4.3 Data Processing Agreements and the Cloud).

Especially in regulated sectors, it is important to assess the provider’s (i) certifications (eg, ISO 27001, ISAE 3402), (ii) incident response procedures, and (iii) historical performance in managing data protection issues.

For high-risk use cases (eg, use of new technologies or large-scale processing of sensitive data), the controller must conduct a DPIA and, if the residual risk remains high, consult the FDPIC (Article 22-23 FADP). Furthermore, a transfer impact assessment (TIA) is necessary when personal data is transferred to a country that does not have an adequate level of data protection and standard contractual clauses are used as the transfer mechanisms (see 6.1 Cross-Border Transfer Regulation).

Data protection requirements are usually only addressed selectively in the cloud service agreement (the main contract), for example, by including provisions such as the following:

• data protection compliance – both the customer and the cloud service provider undertake to comply with applicable data protection laws in relation to the processing of customer data (ie, data submitted, stored, sent or received by the cloud service provider on behalf of the customer);
• confidentiality – both parties undertake not to disclose any confidential information received from the other party to third parties without consent. This provision often also covers customer data;
• customer data backup – the cloud service provider undertakes to create backup copies of the system in which customer data is stored, enabling recovery of this data in the event of data loss; and
• return or release of customer data – during the term of the cloud service agreement and for a defined period thereafter, the cloud service provider enables the customer to extract customer data via a standardised procedure in a machine-readable format.

Additionally, the data processing agreement (DPA), typically included as an annex to the main agreement, serves to reflect data protection requirements (the content and minimum standards for a DPA are described in 4.3 Data Processing Agreements and the Cloud). 

According to data protection law, a customer is usually considered a controller while its cloud service provider is considered a processor (or sub-processor), as the latter carries out processing on behalf of the former. This requires the conclusion of a DPA, which states the parties’ relevant rights and obligations in relation to this data processing. Under Swiss law, a DPA must contain at least:

• processor’s obligation to only process personal data on the controller’s documented instructions;
• appropriate TOMs to ensure an adequate level of data security (see 2.1 Data Security and the Cloud);
• a rule regarding the engagement of sub-processors – either requiring prior approval from the controller or granting the controller the right to object; and
• controller’s right to obtain information and conduct audits to check the processor’s compliance with its contractual and statutory obligations (Article 9 FADP).

In practice, however, it is common to include further content in light of the GDPR’s requirements, for example, the obligations of the processor to:

• allow access to personal data only to persons who are under an appropriate statutory or contractual obligation of confidentiality;
• assist the controller in answering data subject requests, in carrying out DPIAs and in ensuring compliance with its data security obligations; and
• at the choice of the controller, delete or return all personal data to the controller after the end of the provision of services and delete existing copies.

DPAs in the cloud environment are structured in a similar manner to standard DPAs. Particularities may arise from the fact that the providers of the most common cloud services are large, multinational companies such as AWS, Google or Microsoft. These cloud service providers use comparatively comprehensive and detailed DPAs, which are difficult for the average customer to negotiate due to the dominant market position of these providers. However, they offer contractual addenda that can be agreed upon to reflect additional requirements (such as those of the health or financial sector), which at least allows for some flexibility.

Exit strategies aim to enable a smooth in-sourcing or transition to a third-party cloud service provider if the customer wants to stop using or is no longer permitted to use the current provider’s services. Reasons for this may include the provider discontinuing its business or services, the customer having business reasons to change provider, or regulatory requirements. Typical termination and exit strategies for cloud service agreements focus on ensuring continuity of business operations and data protection.

To this end, cloud service agreements should pre-define formats for data exports, prohibit data deletion until the customer confirms successful transfer, and bind the cloud service provider to securely erase all data upon completion. Furthermore, the agreement should include migration assistance by the provider – ie, provision of migration tools, training, technical consulting and other services that enable and facilitate the transition, as well as the applicable conditions (eg, rates, duration, co-operation duties, etc).

The actual migration of services and data from one cloud service provider to another often requires careful planning, including compatibility checks, bandwidth considerations and security precautions during transmission. Customers must ensure that encryption keys and access credentials are appropriately managed to prevent data loss or unauthorised access during the migration process. Depending on the circumstances, it may be advisable to run a table-top or limited live migration to test feasibility and timing and to keep a read-only shadow for business-critical datasets during the transition.

Reporting Obligations Under the ISA

Swiss cloud computing providers and operators must report certain cyber-attacks on their IT resources to the NCSC (Articles 74a-74f ISA). Cyber-attacks are defined as any wilfully caused event involving the use of IT resources that results in the confidentiality, availability or integrity of information being compromised or the traceability of its processing being affected (Article 5(e-f) ISA). A cyber-attack must be reported if it:

• jeopardises the functionality of the critical infrastructure (ie, the cloud computing service) concerned;
• has led to the manipulation or leakage of information;
• has remained undetected for a longer period of time, in particular if there are indications that it was carried out in preparation for further cyber-attacks; or
• is combined with extortion, threats, or coercion.

As of 1 October 2025, failure to comply with this obligation and to subsequently submit a report within the additional period set by the NCSC may result in a fine of up to CHF100,000 (Article 74g-74h ISA). 

Reporting Obligations Under the FADP

In addition, the reporting obligation under the FADP must be observed. The controller must notify the FDPIC of any breach of data security that is likely to lead to a high risk to the data subject’s personality or fundamental rights (Article 24(1) FADP). A breach of data security is defined as a breach of security that leads to the accidental or unlawful loss, deletion, destruction or modification or unauthorised disclosure or access to personal data (Article 5(h) FADP). Whether a high risk is likely to exist must be determined based on the severity and the likelihood of possible impairments to the personality and fundamental rights of the data subjects. According to the FDPIC, the following factors should be considered to evaluate the risk:

• nature and circumstances of the breach;
• number and vulnerability of the data subjects;
• amount and nature of data and the duration of processing; and
• circle and motives of the unauthorised third parties.

The controller must also inform the data subject if the FDPIC so requests or if this is required for their protection (Article 24(4) FADP), in particular where data subjects should take mitigating measures (for example, changing login credentials). Failure to comply with the reporting obligation to the FDPIC or to the data subject is not punishable by a fine. However, this may trigger an investigation and subsequent administrative measures by the FDPIC.

Sector-Specific Reporting Obligations

Further to these general obligations, sector-specific provisions may impose additional reporting duties. For example, under Article 29(2) of the Financial Market Supervision Act (FINMASA), insurers and financial market operators are required to report material cyber-attacks to the Financial Market Supervisory Authority (FINMA).

Cloud service providers are legally obligated and typically also required under the DPA to notify customers of a detected data breach as soon as possible. This notification should include details about the extent of the breach, the data that has been affected, and the remedial steps being taken (Article 24(3) FADP). Under the DPA, cloud service providers are typically also required to co-operate fully with customers and assist them in investigating and remedying data breaches. However, as controllers, customers remain responsible for assessing the impact on data subjects and fulfilling notification obligations under data protection law (see 5.1 Requirements to Report Data Breaches and 5.3 Notifying Data Breaches).

In practice, data breaches in the cloud are typically investigated through co-ordinated efforts between the cloud service provider and the customer, usually based on pre-defined incident response procedures. However, due to their proximity to the incident and technical expertise, cloud service providers typically take the lead in investigating the incident, utilising forensic tools, audit logs, and security monitoring systems to determine the cause and scope of the data breach. Following the (first) investigation, remediation measures must be taken, including isolating compromised systems, patching vulnerabilities and improving security controls to prevent a recurrence.

Timelines and Content of Notifications

Cloud computing providers and operators must report cyber-attacks on their IT resources to the NCSC within 24 hours of becoming aware of the attack (Article 74e(1) ISA). The report must contain information on the organisation subject to the reporting obligation, the type and nature of the cyber-attack, its impact, the measures taken, and, if known, the planned further course of action. If not all the necessary information is available at the time of reporting, the organisation must supplement the report as soon as new information becomes available. Information that could incriminate the reporting individual does not need to be disclosed (Article 74e ISA).

If a data breach has to be reported under the FADP, this must be done “as quickly as possible” (Article 24(1) FADP). In practice, the 72-hour period specified in the GDPR is used as a guideline. As per Article 15(1) DPO, the report to the FDPIC must include:

• the form of the breach;
• its time and duration;
• the categories and approximate amount of personal data concerned;
• the categories and the approximate number of data subjects;
• the consequences, including any risks, for the data subjects;
• the measures that have been taken or are planned in order to remedy the breach and mitigate the consequences (including any risks); and
• the name and the contact details of a contact person.

If not all this information is available at the time of notification, it can be submitted later as soon as it becomes available.

Regarding the duty to inform data subjects, the FADP makes no mention of a timeline. However, to ensure that the information has its intended risk-reducing effect – in particular by enabling data subjects to take swift action – the notification should also be provided as quickly as possible (Article 24(1) FADP). Essentially, the controller must provide the same information as required for the notification to the FDPIC, but in simple and comprehensible language. However, the time and duration of the breach, the categories and amount of personal data concerned and the categories and the number of data subjects are not required (Article 15(3) DPO).

Co-Ordination With Cloud Service Providers

The ISA applies to the cloud service provider and operator, who can independently fulfil their duty to report a cyber-attack without needing input from the customer; however, under the FADP, the notification of a data breach must be co-ordinated between the data controller and the provider. The obligations to report to the FDPIC and to inform the data subjects lie solely with the controller. However, the controller depends on the processor not only to be informed about the data breach, but also to subsequently obtain assistance in fulfilling the reporting obligation (and dealing with the data breach). To this end, it is advisable to include appropriate obligations to provide assistance to the controller in the DPA.

Mechanisms for Cross-Border Transfers

As there are no specific rules for international data transfers in the context of cloud computing, the general data protection regulations apply. In principle, Switzerland permits transfers of personal data abroad only if the destination country guarantees an adequate level of data protection (Article 16(1) FADP). The list of countries deemed to offer adequate protection is maintained by the Federal Council (not the FDPIC, as under the previous law) and published in Annex 1 DPO. In addition to all EEA member states, these include Argentina, Uruguay, the United Kingdom, and the USA (provided that the recipient is certified under the Swiss–US Data Privacy Framework), but – unlike under the GDPR – not Japan or Korea.

Where a country is not listed as adequate (including US recipients without Swiss–US Data Privacy Framework certification), transfers are only permissible with additional safeguards. This is the case if an appropriate level of data protection is guaranteed by (Article 16(2) FADP):

• a treaty under international law;
• data protection clauses in an agreement between the controller or the processor and its contractual partner, notification of which has been given to the FDPIC beforehand;
• specific guarantees drawn up by the competent federal body, notification of which has been given to the FDPIC beforehand;
• standard data protection clauses that the FDPIC has approved, issued or recognised beforehand; or
• binding corporate rules that have been approved in advance by the FDPIC or by the authority responsible for data protection in a State that guarantees an adequate level of protection.

As per Article 17 FADP, in certain exceptional cases, transfers may be justified on the basis of:

• explicit consent from the data subject;
• the conclusion or performance of a contract; or
• the establishment exercise or enforcement of legal rights before a court or another competent foreign authority.

However, these exceptions are a precarious basis for international data transfers and should therefore not be used for routine transmissions.

Regulation of Cross-Border Transfers in Data Processing Agreements

In practice, the standard contractual clauses (SCCs) are the most important transfer mechanism. The EU-SCCs have been approved by the FDPIC, provided they are used alongside a Swiss addendum that adjusts the references to the GDPR and the EU member states and specifies the competent supervisory authority, applicable law and place of jurisdiction.

International data transfers are usually addressed in the DPA, which incorporates the SCCs with the Swiss addendum. To secure onward transfers by the cloud service provider, the customer should contractually require the provider to agree to the SCCs (with the necessary addendum) with its recipients. Additionally, the customer may contractually oblige the cloud service provider to carry out a transfer impact assessment in such cases and to submit it to the customer upon request.

Data localisation requirements stipulate that personal data must be stored and processed within a specific country or region. Switzerland imposes no general localisation obligation on cloud computing. However, sectoral frameworks – especially in the finance and health sectors – and public procurement preferences can effectively push for data storage and processing in Switzerland, or at least within the EU/EEA. For customers, this means ensuring that the cloud service provider discloses the location of its data centres and sub-processors, and selecting providers that can offer regional data centres, along with contractual guarantees on data residency. Providers, in turn, must implement technical and organisational measures to segregate and control data flows to ensure compliance with localisation requirements. While data localisation may enhance trust through closer oversight, it may also increase costs, reduce flexibility, and restrict access to global innovation.

Conflicts of law are only indirectly addressed in cross-border data transfers, in that the requirements for such transfers depend on the applicability of different laws and the varying levels of protection they offer: If an importing country guarantees an adequate level of data protection from Switzerland’s perspective, personal data may be transferred without further ado. Otherwise, the Swiss level of protection must be achieved through specific safeguards (see 6.1 Cross-Border Transfer Regulation).

In recent years, the main challenge and risk associated with international data transfers has been government access to data – both in terms of assessing whether a country has an adequate level of data protection and, if not, whether a transfer is still possible. This is particularly true for cloud computing, since storing data in the cloud may increase the risk of it being accessed by foreign law enforcement agencies and intelligence services. However, even if such access is (theoretically) possible and the data-importing country does not provide adequate data protection, using a cloud service provider in that country is not ruled out. Usually, the risk of such access by public authorities is evaluated in a TIA and mitigated further by additional protective measures, such as encryption and customer-side key management. If access by public authorities appears highly unlikely in the given circumstances, using a cloud service provider in such a country is permissible.

In Switzerland, compliance audits in cloud environments are generally based on contractual provisions in the cloud service agreement or the DPA. The FADP does not grant the controller (ie, the customer) a statutory right to audit but obliges the controller to ensure that the processor (ie, the cloud service provider) is able to guarantee data security. This requires the controller to obtain a contractual right to audit the processor. In practice, customers only conduct audits when there is a specific reason, such as a data leak or a similar incident. Otherwise, they usually rely on third-party certifications (eg, ISO 27001) or reports from regular audits carried out on behalf of the provider (eg, based on the standard ISAE 3402).

Audits generally examine whether the cloud service provider complies with its legal, contractual and certification obligations. Emphasis is usually placed on data security and the provider’s TOMs. The specific focus of compliance audits otherwise depends on the customer’s sector of activity and whether the audit is carried out within the framework of a certification or audit standard. Any audit concludes with a report, which is made available to the customer, the provider, and possibly third parties such as the provider’s potential customers. The integrity and accuracy of the audit report are generally ensured by engaging independent auditors and relying on recognised standards. Whether and how audit findings are addressed is largely a contractual issue: DPAs typically require the provider to remedy any deficiencies within a specified timeframe and, where applicable, to bear the costs of the audit.

Although the FADP does not impose statutory penalties for non-compliance with audit requirements, failure to maintain appropriate controls may result in an investigation by the FDPIC and potential administrative actions. In regulated sectors, this may also result in an investigation by the relevant supervisory authority, such as FINMA, and corresponding administrative measures. If the cloud service provider, acting as a processor, fails to comply with the contractual audit rights, contractual consequences may arise, such as termination of the contract, indemnification or the imposition of a contractual penalty.