Public cloud compliance in Switzerland in 2026

Public-cloud compliance is a strategic arbitration for regulated organisations in Switzerland. Since the revised nFADP entered into force in September 2023, data-protection duties have tightened. Finance, health and public-sector firms must now show where their data is stored and who can reach it. This article details the main causes of public-cloud non-compliance in Switzerland, the applicable regulatory frames and the operational controls regulated firms need. This is not legal advice.

For CIOs, CTOs and cloud architects, a move to public cloud is no longer an isolated technical decision. It binds regulatory compliance, cost control and reversibility. Organisations that neglect those dimensions expose themselves to financial sanctions and measurable reputational risk.

Key points: public-cloud compliance in Switzerland in 2026

• The revised nFADP of September 2023 tightens Swiss organisations’ duties on location and traceability of personal data.
• The US CLOUD Act can let US authorities reach data hosted by AWS, Azure and GCP even if the servers sit in Switzerland.
• Hikube is a sovereign cloud on three Swiss datacenters (Geneva, Gland, Lucerne), with volume replication in the mode you choose. It supports an nFADP/GDPR file (DPA, ISO 27001 SQS). It does not certify your nFADP or FINMA dossier.
• FINMA (Circulars 2018/3 and 2023/1) requires specific contractual clauses for any essential outsourcing to the cloud.
• A documented exit strategy and portable formats reduce lock-in risk.

What are the main regulatory frames for cloud in Switzerland?

Several rules frame how Swiss organisations use cloud services. They define duties on data protection, outsourcing and operational security.

Revised nFADP and what it means for cloud

The revised Federal Act on Data Protection entered into force on 1 September 2023. It strengthens the duties of controllers. Organisations must now ensure that cloud processors treat data according to the controller’s instructions.

nFADP also restricts transfers to countries that do not offer an adequate level of protection. The United States is treated as non-adequate for this analysis because of identified gaps in constitutional safeguards for authority access. A transfer to a US provider needs extra measures: standard contractual clauses and, depending on the data processed, encryption whose keys stay under the organisation’s exclusive control.

FINMA circulars for financial institutions

FINMA frames cloud outsourcing by financial institutions through several instruments. Circular 2018/3 defines the minimum contractual requirements for any significant outsourcing. It requires, among other things, documented audit rights, notification of subcontractors and reversibility clauses.

Circular 2023/1, in force since 1 January 2024, tightens operational-risk and cyber-resilience requirements. It specifically targets the management of critical data and cyber risk in cloud environments. Institutions must demonstrate real-time visibility on access and incidents. See FINMA cloud clauses.

Health and specific duties

Health establishments handle patient data under medical secrecy. Outsourcing to the cloud means checking that the provider can be qualified as an auxiliary under professional-secrecy rules. Health data are sensitive personal data under nFADP, which requires stronger technical measures. Hikube is not a French HDS host and is not HDS-certified: the posture is Swiss (nFADP) for establishments and vendors that must stay in Switzerland, with data in Geneva, Gland and Lucerne.

In practice that means encryption at rest and in transit, with key management under the establishment’s control. Exclusive location in Switzerland reduces the risk of access by foreign authorities. It does not remove Swiss mutual legal assistance.

Why does the US CLOUD Act challenge Swiss compliance?

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act), adopted in 2018, gives US authorities an extraterritorial access power. The text applies to any company under US jurisdiction, independently of the physical location of the servers.

Extraterritorial reach and implications

AWS, Azure and GCP are US entities. Their European subsidiaries and datacenters in Switzerland remain under the CLOUD Act. On a US authority request, those providers can be compelled to produce data stored in Switzerland without informing the customer.

Microsoft Corp. v. United States clarified that reach. The US government obtained access to data stored in Ireland. That decision has direct consequences for Swiss organisations using US hyperscalers. Detail: CLOUD Act and Swiss law.

Tension with Swiss requirements

The CLOUD Act conflicts with several principles of Swiss law. Article 271 of the Swiss Criminal Code prohibits acts performed for a foreign state without official authorisation. Disclosure of data to US authorities outside mutual legal assistance can constitute a criminal offence.

For financial institutions, a breach of banking secrecy (art. 47 of the Banking Act) exposes them to criminal and administrative sanctions. FINMA measures can include withdrawal of authorisation in the most serious cases. Not legal advice.

What are the main causes of public-cloud non-compliance?

Compliance incidents show recurring pathologies. They mainly hit data-location mapping, contract management and access control.

1. No map of data flows

Symptom: organisations deploy cloud services without documenting precisely where data is stored, replicated and processed. Metadata, logs and telemetry are often neglected.

Impact: inability to answer regulators on data location. FINMA reviews or nFADP audits reveal undocumented transfers to third jurisdictions. Organisations report incident-response time multiplied by three to five when the map is missing. Industry observation, not a Hikube metric.

Solution: build an exhaustive data-flow map before any cloud deployment. Document replication sites, subcontractors and remote access. Update that documentation on every architecture change.

2. Insufficient contractual clauses

Symptom: accepting the cloud provider’s general terms without negotiating compliance clauses. No effective audit rights and no documented reversibility clauses.

Impact: in an incident or a regulatory request, the organisation lacks the contractual levers to obtain the information it needs. Compliance audits fail for lack of visibility on the provider’s practices.

Solution: negotiate specific clauses covering audit rights, notification of subcontractors, location commitments and exit procedures. Require SOC 2-type audit reports or ISO 27001 certifications with an explicit cloud scope. Hikube publishes ISO 27001 (SQS); it does not invent SOC 2 as a Hikube claim.

3. Encryption without key control

Symptom: turning on the encryption the cloud provider offers without checking who holds the keys. Provider-managed keys offer no protection against the provider itself.

Impact: data remains reachable by the provider and, by extension, by authorities that can compel it to cooperate. Encryption then gives only an illusory protection against extraterritorial access risk.

Solution: implement key management under the organisation’s exclusive control (customer-managed keys or BYOK) where the product allows it. For the most sensitive data, consider client-side encryption before transmission to the cloud.

4. Neglect of secondary data

Symptom: focus on business data while forgetting telemetry, logs, metadata and support data generated by using the cloud service.

Impact, those secondary data can reveal sensitive information about users, business processes and behaviour. They are often processed in third jurisdictions without a contractual restriction.

Solution: audit the types of secondary data each cloud service collects. Demand the same location and confidentiality guarantees for those data as for primary business data.

5. No exit strategy

Symptom: deploying workloads on proprietary provider services without documenting migration procedures to another environment. Heavy use of non-portable features.

Impact: structural lock-in that makes any migration technically and financially prohibitive. On a regulatory change or a compliance incident, the organisation has no viable alternative.

Solution: prefer open standards (Kubernetes, S3, REST APIs). Document and regularly test exit procedures. Hikube uses open standards compatible with kubectl, Terraform and the AWS CLI, which allows reversibility without rewriting applications. Do not invent a Kubernetes version as a Hikube SKU.

How to structure an effective cloud-compliance approach

An effective cloud-compliance strategy rests on four pillars: governance, technical architecture, operational controls and continuous surveillance.

Establish formalised cloud governance

Define a governance frame that clearly assigns responsibilities for cloud compliance. Identify an owner (Cloud Security Officer or equivalent) with the authority to validate or refuse non-compliant deployments.

Document a cloud-use policy that defines the data categories allowed per service type and per provider. That policy must be validated by legal, compliance and security.

Architect for compliance

Integrate compliance requirements from the design of cloud architectures. Classify data before any deployment. Data under strict regulatory duties (finance, health, sensitive personal data) need environments with location guarantees.

Hikube offers sovereign infrastructure on three Swiss datacenters (Gland, Lucerne, Geneva). That architecture keeps data in Switzerland while targeting high availability. Volume replication is sync or async in the volume price, not a separate multi-AZ SKU. Sync aims at stronger consistency; that is not a published RPO=0 promise.

Implement measurable technical controls

Deploy technical controls whose effectiveness can be measured and audited. Frequent examples: client-key encryption can be verified by auditing key-management policies; data location can be checked by infrastructure queries; access can be traced by immutable logs.

Avoid purely declarative controls whose verification depends only on the provider’s assertions. Require technical evidence or independent audits.

Watch the compliance posture continuously

Compliance is not a static state. Configurations evolve, providers change practices, regulations change. Put continuous surveillance of the compliance posture in place.

Use Cloud Security Posture Management (CSPM) tools to detect configuration drift automatically. Regularly audit the provider’s subcontractors and their locations. Hikube does not prescribe a VictoriaMetrics or VictoriaLogs SKU; run the observability stack you operate (Grafana-class metrics and logs) in your tenant so evidence stays under your control.

What contractual requirements are essential for cloud?

Cloud contracts must cover several compliance dimensions. Requirements vary by sector and data criticality, but some elements are systematically required.

Location and data transfers

The contract must specify the authorised storage and processing sites. For organisations under location duties, a restrictive clause must forbid any transfer outside the authorised territory, including for support data and metadata.

Require prior notification on a change of subcontractor or processing site, with a right to terminate if the change is not acceptable.

Audit and control rights

The contract must provide effective audit rights to verify the provider’s commitments. Those rights can take several forms: on-site audit, access to independent audit reports (SOC 2, ISO 27001), or technical audit via automated tools.

For FINMA institutions, the supervisor must have a contractual right of access to relevant information on the outsourced functions.

Incident management and notification

Define contractually the notification delays if a security incident affects the data. nFADP requires notification to the FDPIC as soon as possible for breaches that present a high risk. The cloud contract must allow those delays to be met.

Document respective responsibilities for investigation and remediation. The provider must commit to cooperate actively in an incident.

Reversibility and end of contract

Provide contractually the end-of-relationship modalities: export formats, restitution delays, certified destruction procedures. Those clauses are essential to avoid lock-in and keep freedom of choice.

Regularly test exit procedures to verify technical feasibility. An untested exit plan offers no guarantee. Those RTO/RPO figures are your design targets, not published Hikube credits.

How to evaluate cloud providers on compliance

Cloud-provider evaluation must cover several dimensions: legal, technical, operational and financial. That evaluation must be documented and updated periodically.

Analysis of the applicable jurisdiction

Identify the jurisdiction of the contracting entity and of the parent. A Swiss provider whose parent is US can remain under the CLOUD Act. Check the absence of legal ties to risk jurisdictions.

Examine general terms to identify jurisdiction and applicable-law clauses. Prefer Swiss law and a forum in Switzerland for disputes. Hikube is operated by Hidora SA under Swiss law.

Verification of the physical infrastructure

Audit the real location of the datacenters used. Some providers offer location options but use shared infrastructure with international replication by default.

Check datacenter certifications (ISO 27001, SOC 2) and their exact scope. A certification on the head office does not imply a certification of the datacenters. Hikube ISO 27001 is issued by SQS on the published scope.

Evaluation of security maturity

Analyse the provider’s security practices: access management, encryption, monitoring, incident response. Require tangible evidence (audit reports, certifications) rather than statements.

Evaluate the provider’s transparency on government access requests. Some providers publish transparency reports; others refuse to communicate on that topic.

Financial stability and durability

Evaluate the provider’s financial solidity. A provider failure can create continuity and compliance risks if data become unreachable or if contractual documentation is lost.

Prefer providers with a demonstrated history and an established customer base in regulated sectors. Do not invent customer counts as Hikube claims.

Which operational controls to put in place on a sovereign cloud?

Operational controls translate compliance requirements into daily practice. They should be automated as far as possible to guarantee systematic application.

Identity and access management

Implement role-based access control (RBAC) with least privilege. Document and regularly audit access rights to cloud environments.

Enable multi-factor authentication for all administrative access. Centralise identity management via a compatible identity provider (SAML, OIDC) to keep a unified view.

Encryption and key management

Encrypt data at rest and in transit. For sensitive data, use organisation-managed keys (customer-managed keys) where the product allows it. Document key-rotation and recovery procedures.

Regularly audit key use to detect abnormal access. Hardware Security Module (HSM) solutions offer extra guarantees for the most critical keys. Do not invent a Hikube HSM SKU if it is not on the catalogue.

Logging and traceability

Enable exhaustive logging of access and changes on cloud resources. Keep logs in immutable storage to guarantee their integrity at audit time.

Define retention durations that match regulatory requirements. FINMA institutions must keep certain logs for 10 years. That is a regulatory duty on the institution, not a published Hikube retention credit.

Detection and incident response

Deploy anomaly and suspicious-behaviour detection. Define documented and tested incident-response procedures.

Integrate cloud alerts into the global security-incident process. Document escalation thresholds to the supervisor or competent authorities.

How Hikube answers Swiss compliance requirements

Hikube is a sovereign cloud platform designed for regulated organisations in Switzerland. Its architecture and operating model integrate compliance controls. It supports your file; it does not certify nFADP or FINMA.

Infrastructure in Switzerland without an extraterritorial parent

Hikube operates exclusively on three datacenters in Switzerland (Gland, Lucerne, Geneva). The company is Swiss-law (Hidora SA), without a US parent. That legal structure means it is not under the CLOUD Act or an equivalent extraterritorial statute as a US-controlled group would be.

Data can be replicated across the three sites in the volume-replication mode you choose, targeting high availability (Hikube publishes 99.99% on listed products) without transferring data outside Switzerland. This article does not invent extra SLA credits.

Integrated regulatory support

Hikube/Hidora is ISO 27001 certified by SQS. The certificate and its exact scope are obtained from an engineer: the PDF is not published, and this article does not infer a scope from it. Evidence: security and compliance. Managed databases and storage include encryption by default as published.

Regulated customers can obtain a Data Processing Agreement (DPA) aligned with nFADP and GDPR. A processing register extract can be provided on request to facilitate compliance audits. Hikube does not certify your dossier. No ISO 27018 claim. Not French HDS.

Open standards and reversibility

Hikube uses standard technologies: CNCF-certified Kubernetes (hosted, Talos workers, Cilium, KCSP), S3-compatible storage, documented REST APIs. That approach supports workload portability and reduces lock-in. Do not invent a Kubernetes version pin.

Technical teams can use their usual tools (kubectl, Terraform, Helm, Flux CD) without adaptation. A migration from or to Hikube does not require application rewrite.

Isolation and customer control

Each customer has an isolated tenant with network, storage and identity separation. That isolation avoids interference between customers and facilitates scope audits.

The monitoring stack you operate stays in the customer tenant. Metrics and logs remain under the customer’s exclusive control, without sharing with other tenants. Support in French and English, not German support.

Conclusion: how to succeed at cloud compliance in Switzerland

Public-cloud compliance in Switzerland rests on a structured approach that combines regulatory analysis, technical architecture and operational controls. Regulated organisations must evaluate each cloud provider on its jurisdiction, certifications and security practices.

The main risks are extraterritorial access to data (CLOUD Act), the absence of a data-flow map and contractual gaps. Those risks can be mitigated by choosing a sovereign provider, using open standards and putting verifiable technical controls in place.

The objective: a decision framework that lets IT decision-makers choose and operate cloud services while respecting Swiss regulatory requirements. See nFADP duties and security and compliance.

FAQ on public-cloud compliance in Switzerland

Does the US CLOUD Act apply to data stored in Switzerland?

The CLOUD Act applies to any entity under US jurisdiction, independently of server location. AWS, Azure and GCP can be compelled to produce data stored in Switzerland to US authorities. Hikube, as a Swiss-law company without a US capital link, is not under the CLOUD Act. Swiss mutual legal assistance still exists: a Swiss operator does not mean no authority can ever obtain data.

Which certifications must a cloud provider have for the Swiss financial sector?

FINMA does not impose a specific certification, but requires that the financial institution can audit its provider. ISO 27001 and SOC 2 Type II are recognised evidence of security maturity. Hikube/Hidora holds ISO 27001, issued by SQS; the scope is available on request. It does not claim SOC 2. It does not certify your FINMA file.

How to guarantee nFADP compliance on a cloud deployment?

nFADP compliance for cloud rests on three pillars: data location in a country offering an adequate level of protection, a processor contract aligned with nFADP art. 9, and appropriate technical measures. Choosing an exclusively Swiss provider such as Hikube simplifies that demonstration. It does not replace your file.

What are the cloud non-compliance risks for a FINMA institution?

Financial institutions expose themselves to administrative measures that can go as far as withdrawal of authorisation. Responsible persons can face individual sanctions including fines and bans on practising. A breach of banking secrecy (art. 47 BA) is a criminal offence that can carry prison. Not legal advice.

How to prepare a FINMA audit on cloud use?

Document cloud contracts, risk analyses and controls exhaustively. Keep an up-to-date map of data and its location. Prepare audit evidence (SOC 2 reports if you have them, certifications) and incident-management procedures. Hikube provides documentation needed for regulatory audits on request. You still run the audit.

GPU catalogue cards in the 14-day trial, if your regulated workloads need them: L4, L40S, A100-80, RTX 6000 Pro, H100, H200. Windows is not a catalogue product. Hikube does not bill egress in the TCO comparison. Talk to the team.