Public-Cloud-Compliance in der Schweiz 2026

Public-Cloud-Compliance ist ein strategisches Schiedsverfahren für regulierte Organisationen in der Schweiz. Seit Inkrafttreten des revidierten nDSG im September 2023 haben sich die Datenschutzpflichten verschärft. Unternehmen in Finance, Gesundheit und öffentlicher Hand müssen nun zeigen, wo ihre Daten gespeichert sind und wer darauf zugreifen kann. Dieser Artikel detailliert die Hauptursachen von Public-Cloud-Nichtkonformität in der Schweiz, die anwendbaren regulatorischen Rahmen und die operationellen Kontrollen, die regulierte Firmen brauchen. Das ist keine Rechtsberatung.

Für CIOs, CTOs und Cloud-Architekten ist der Wechsel in die Public Cloud keine isolierte technische Entscheidung mehr. Er bindet regulatorische Compliance, Kostenkontrolle und Reversibilität. Organisationen, die diese Dimensionen vernachlässigen, setzen sich finanziellen Sanktionen und messbarem Reputationsrisiko aus.

Kernpunkte: Public-Cloud-Compliance in der Schweiz 2026

• Das revidierte nDSG vom September 2023 verschärft die Pflichten Schweizer Organisationen zu Standort und Nachvollziehbarkeit von Personendaten.
• Der US CLOUD Act kann US-Behörden den Zugriff auf Daten erlauben, die AWS, Azure und GCP hosten, auch wenn die Server in der Schweiz stehen.
• Hikube ist eine souveräne Cloud auf drei Schweizer Rechenzentren (Genf, Gland, Luzern), mit Volume-Replikation im gewählten Modus. Es stützt ein nDSG/DSGVO-Dossier (DPA, ISO 27001 SQS). Es zertifiziert Ihr nDSG- oder FINMA-Dossier nicht.
• Die FINMA (Rundschreiben 2018/3 und 2023/1) verlangt spezifische Vertragsklauseln für jede wesentliche Auslagerung in die Cloud.
• Eine dokumentierte Exit-Strategie und portable Formate senken das Lock-in-Risiko.

Was sind die wichtigsten regulatorischen Rahmen für Cloud in der Schweiz?

Mehrere Regeln rahmen, wie Schweizer Organisationen Cloud-Dienste nutzen. Sie definieren Pflichten zu Datenschutz, Auslagerung und operationeller Sicherheit.

Revidiertes nDSG und was es für die Cloud bedeutet

Das revidierte Bundesgesetz über den Datenschutz ist am 1. September 2023 in Kraft getreten. Es stärkt die Pflichten der Verantwortlichen. Organisationen müssen nun sicherstellen, dass Cloud-Auftragsbearbeiter Daten nach den Weisungen des Verantwortlichen behandeln.

Das nDSG beschränkt auch Transfers in Länder, die kein angemessenes Schutzniveau bieten. Die Vereinigten Staaten gelten in dieser Analyse als nicht angemessen wegen identifizierter Lücken in den verfassungsrechtlichen Garantien für Behördenzugriff. Ein Transfer zu einem US-Provider braucht Extra-Massnahmen: Standardvertragsklauseln und, je nach den bearbeiteten Daten, Verschlüsselung, deren Schlüssel unter der ausschliesslichen Kontrolle der Organisation bleiben.

FINMA-Rundschreiben für Finanzinstitute

Die FINMA rahmt Cloud-Outsourcing durch Finanzinstitute über mehrere Instrumente. Das Rundschreiben 2018/3 definiert die minimalen vertraglichen Anforderungen für jede wesentliche Auslagerung. Es verlangt unter anderem dokumentierte Auditrechte, Meldung von Unterauftragnehmern und Reversibilitätsklauseln.

Das Rundschreiben 2023/1, in Kraft seit 1. Januar 2024, verschärft die Anforderungen zu operationellen Risiken und Cyber-Resilienz. Es zielt spezifisch auf die Verwaltung kritischer Daten und Cyberrisiken in Cloud-Umgebungen. Institute müssen Echtzeit-Sichtbarkeit auf Zugriffe und Incidents nachweisen. Siehe FINMA-Cloud-Klauseln.

Gesundheit und spezifische Pflichten

Gesundheitseinrichtungen verarbeiten Patientendaten unter dem Berufsgeheimnis. Die Auslagerung in die Cloud heisst zu prüfen, dass der Provider als Hilfsperson im Sinne der Berufsgeheimnisregeln qualifiziert werden kann. Gesundheitsdaten sind besonders schützenswerte Personendaten nach nDSG, was stärkere technische Massnahmen verlangt. Hikube ist kein französischer HDS-Host und nicht HDS-zertifiziert: die Haltung ist schweizerisch (nDSG) für Einrichtungen und Anbieter, die in der Schweiz bleiben müssen, mit Daten in Genf, Gland und Luzern.

In der Praxis heisst das Verschlüsselung at rest und in Transit, mit Schlüsselverwaltung unter Kontrolle der Einrichtung. Ausschliesslicher Standort in der Schweiz senkt das Risiko eines Zugriffs durch ausländische Behörden. Es nimmt die schweizerische Rechtshilfe nicht weg.

Warum stellt der US CLOUD Act die Schweizer Compliance in Frage?

Der Clarifying Lawful Overseas Use of Data Act (CLOUD Act), angenommen 2018, gibt US-Behörden eine extraterritoriale Zugriffsmacht. Der Text gilt für jedes Unternehmen unter US-Jurisdiktion, unabhängig vom physischen Standort der Server.

Extraterritoriale Reichweite und Implikationen

AWS, Azure und GCP sind US-Entitäten. Ihre europäischen Töchter und Rechenzentren in der Schweiz bleiben unter dem CLOUD Act. Auf Verlangen einer US-Behörde können diese Provider gezwungen werden, in der Schweiz gespeicherte Daten herauszugeben, ohne den Kunden zu informieren.

Microsoft Corp. gegen die Vereinigten Staaten hat diese Reichweite geklärt. Die US-Regierung erhielt Zugriff auf in Irland gespeicherte Daten. Diese Entscheidung hat direkte Folgen für Schweizer Organisationen, die US-Hyperscaler nutzen. Detail: CLOUD Act und Schweizer Recht.

Spannung mit Schweizer Anforderungen

Der CLOUD Act kollidiert mit mehreren Prinzipien des Schweizer Rechts. Artikel 271 des Schweizerischen Strafgesetzbuchs verbietet Handlungen für einen ausländischen Staat ohne amtliche Bewilligung. Die Offenlegung von Daten an US-Behörden ausserhalb der Rechtshilfe kann eine Straftat darstellen.

Für Finanzinstitute setzt ein Bruch des Bankgeheimnisses (Art. 47 BankG) sie straf- und verwaltungsrechtlichen Sanktionen aus. FINMA-Massnahmen können in den schwersten Fällen den Entzug der Bewilligung umfassen. Keine Rechtsberatung.

Was sind die Hauptursachen von Public-Cloud-Nichtkonformität?

Compliance-Incidents zeigen wiederkehrende Pathologien. Sie treffen vor allem Datenstandort-Kartierung, Vertragsverwaltung und Zugriffskontrolle.

1. Keine Karte der Datenflüsse

Symptom: Organisationen deployen Cloud-Dienste, ohne präzise zu dokumentieren, wo Daten gespeichert, repliziert und bearbeitet werden. Metadaten, Logs und Telemetrie werden oft vernachlässigt.

Impact: Unfähigkeit, Regulatoren zum Datenstandort zu antworten. FINMA-Reviews oder nDSG-Audits decken undokumentierte Transfers in Drittjurisdiktionen auf. Organisationen berichten, dass die Incident-Response-Zeit sich verdrei- bis verfünffacht, wenn die Karte fehlt. Branchenbeobachtung, keine Hikube-Metrik.

Lösung: eine exhaustive Datenflusskarte vor jedem Cloud-Deployment bauen. Replikationssites, Unterauftragnehmer und Fernzugriff dokumentieren. Diese Dokumentation bei jeder Architekturänderung aktualisieren.

2. Unzureichende Vertragsklauseln

Symptom: die AGB des Cloud-Providers akzeptieren, ohne Compliance-Klauseln zu verhandeln. Keine wirksamen Auditrechte und keine dokumentierten Reversibilitätsklauseln.

Impact: bei einem Incident oder einer regulatorischen Anfrage fehlen der Organisation die vertraglichen Hebel, um die nötigen Informationen zu erhalten. Compliance-Audits scheitern aus Mangel an Sichtbarkeit auf die Praktiken des Providers.

Lösung: spezifische Klauseln verhandeln, die Auditrechte, Meldung von Unterauftragnehmern, Standortzusagen und Exit-Verfahren decken. Auditberichte der SOC-2-Klasse oder ISO-27001-Zertifizierungen mit ausdrücklichem Cloud-Scope verlangen. Hikube publiziert ISO 27001 (SQS); es erfindet kein SOC 2 als Hikube-Anspruch.

3. Verschlüsselung ohne Schlüsselkontrolle

Symptom: die vom Cloud-Provider angebotene Verschlüsselung einschalten, ohne zu prüfen, wer die Schlüssel hält. Provider-verwaltete Schlüssel bieten keinen Schutz gegen den Provider selbst.

Impact: Daten bleiben für den Provider erreichbar und, in der Verlängerung, für Behörden, die ihn zur Kooperation zwingen können. Verschlüsselung gibt dann nur einen illusorischen Schutz gegen extraterritoriales Zugriffsrisiko.

Lösung: Schlüsselverwaltung unter ausschliesslicher Kontrolle der Organisation implementieren (Customer-Managed Keys oder BYOK), wo das Produkt es erlaubt. Für die sensibelsten Daten Client-Side-Verschlüsselung vor der Übertragung in die Cloud erwägen.

4. Vernachlässigung sekundärer Daten

Symptom: Fokus auf Geschäftsdaten, während Telemetrie, Logs, Metadaten und Supportdaten vergessen werden, die die Nutzung des Cloud-Dienstes erzeugt.

Impact, diese Sekundärdaten können sensible Informationen über Nutzer, Geschäftsprozesse und Verhalten offenbaren. Sie werden oft in Drittjurisdiktionen ohne vertragliche Einschränkung bearbeitet.

Lösung: die Typen sekundärer Daten auditen, die jeder Cloud-Dienst sammelt. Dieselben Standort- und Vertraulichkeitsgarantien für diese Daten verlangen wie für primäre Geschäftsdaten.

5. Keine Exit-Strategie

Symptom: Workloads auf proprietären Provider-Diensten deployen, ohne Migrationsverfahren in eine andere Umgebung zu dokumentieren. Starke Nutzung nicht portabler Features.

Impact: strukturelles Lock-in, das jede Migration technisch und finanziell prohibitiv macht. Bei einer regulatorischen Änderung oder einem Compliance-Incident hat die Organisation keine tragfähige Alternative.

Lösung: offene Standards bevorzugen (Kubernetes, S3, REST-APIs). Exit-Verfahren dokumentieren und regelmässig testen. Hikube nutzt offene Standards, kompatibel mit kubectl, Terraform und der AWS CLI, was Reversibilität ohne Anwendungsneuschreibung erlaubt. Keine Kubernetes-Versionspin als Hikube-SKU erfinden.

Wie eine wirksame Cloud-Compliance-Haltung strukturieren

Eine wirksame Cloud-Compliance-Strategie ruht auf vier Säulen: Governance, technische Architektur, operationelle Kontrollen und kontinuierliche Überwachung.

Formalisierte Cloud-Governance etablieren

Einen Governance-Rahmen definieren, der Verantwortlichkeiten für Cloud-Compliance klar zuweist. Einen Owner identifizieren (Cloud Security Officer oder gleichwertig) mit der Autorität, nicht konforme Deployments zu validieren oder abzulehnen.

Eine Cloud-Nutzungspolitik dokumentieren, die die erlaubten Datenkategorien pro Diensttyp und Provider definiert. Diese Politik muss von Legal, Compliance und Sicherheit validiert werden.

Für Compliance architektieren

Compliance-Anforderungen ab der Konzeption der Cloud-Architekturen integrieren. Daten vor jedem Deployment klassifizieren. Daten unter strengen regulatorischen Pflichten (Finance, Gesundheit, besonders schützenswerte Personendaten) brauchen Umgebungen mit Standortgarantien.

Hikube bietet souveräne Infrastruktur auf drei Schweizer Rechenzentren (Gland, Luzern, Genf). Diese Architektur hält Daten in der Schweiz und zielt auf hohe Verfügbarkeit. Volume-Replikation ist sync oder async im Volume-Preis, kein separates Multi-AZ-SKU. Sync zielt auf stärkere Konsistenz; das ist keine veröffentlichte RPO=0-Zusage.

Messbare technische Kontrollen implementieren

Technische Kontrollen deployen, deren Wirksamkeit gemessen und auditiert werden kann. Häufige Beispiele: Client-Key-Verschlüsselung kann durch Audit der Schlüsselverwaltungspolitiken geprüft werden; der Datenstandort kann durch Infrastrukturabfragen kontrolliert werden; Zugriffe können durch unveränderliche Logs nachverfolgt werden.

Rein deklarative Kontrollen vermeiden, deren Prüfung nur von den Behauptungen des Providers abhängt. Technische Beweise oder unabhängige Audits verlangen.

Die Compliance-Haltung kontinuierlich überwachen

Compliance ist kein statischer Zustand. Konfigurationen entwickeln sich, Provider ändern Praktiken, Regulierungen ändern sich. Eine kontinuierliche Überwachung der Compliance-Haltung einrichten.

Cloud-Security-Posture-Management-Werkzeuge (CSPM) nutzen, um Konfigurationsdrift automatisch zu erkennen. Unterauftragnehmer des Providers und ihre Standorte regelmässig auditen. Hikube schreibt kein VictoriaMetrics- oder VictoriaLogs-SKU vor; den Observability-Stack betreiben, den Sie fahren (Metriken und Logs der Grafana-Klasse) in Ihrem Tenant, damit Evidenz unter Ihrer Kontrolle bleibt.

Welche vertraglichen Anforderungen sind für Cloud wesentlich?

Cloud-Verträge müssen mehrere Compliance-Dimensionen decken. Anforderungen variieren nach Sektor und Datenkritikalität, aber einige Elemente sind systematisch nötig.

Standort und Datentransfers

Der Vertrag muss die erlaubten Speicher- und Bearbeitungsorte ausdrücklich nennen. Für Organisationen unter Standortpflichten muss eine restriktive Klausel jeden Transfer ausserhalb des erlaubten Gebiets verbieten, inklusive Supportdaten und Metadaten.

Vorgängige Meldung bei Änderung eines Unterauftragnehmers oder Bearbeitungsorts verlangen, mit Kündigungsrecht, wenn die Änderung nicht akzeptabel ist.

Audit- und Kontrollrechte

Der Vertrag muss wirksame Auditrechte vorsehen, um die Zusagen des Providers zu prüfen. Diese Rechte können mehrere Formen annehmen: Audit vor Ort, Zugang zu unabhängigen Auditberichten (SOC 2, ISO 27001) oder technisches Audit über automatisierte Werkzeuge.

Für FINMA-Institute muss der Supervisor ein vertragliches Zugangsrecht zu relevanten Informationen über die ausgelagerten Funktionen haben.

Incident-Management und Meldung

Vertraglich die Meldefristen definieren, wenn ein Sicherheitsincident die Daten betrifft. Das nDSG verlangt eine Meldung an den EDÖB so rasch wie möglich bei Verletzungen mit hohem Risiko. Der Cloud-Vertrag muss erlauben, diese Fristen einzuhalten.

Die jeweiligen Verantwortlichkeiten für Untersuchung und Behebung dokumentieren. Der Provider muss sich verpflichten, bei einem Incident aktiv zu kooperieren.

Reversibilität und Vertragsende

Vertraglich die Modalitäten des Beziehungsendes vorsehen: Exportformate, Rückgabefristen, zertifizierte Vernichtungsverfahren. Diese Klauseln sind wesentlich, um Lock-in zu vermeiden und Wahlfreiheit zu halten.

Exit-Verfahren regelmässig testen, um die technische Machbarkeit zu prüfen. Ein ungetesteter Exit-Plan bietet keine Garantie. Diese RTO/RPO-Zahlen sind Ihre Designziele, keine veröffentlichten Hikube-Kredite.

Wie Cloud-Provider auf Compliance bewerten

Die Bewertung von Cloud-Providern muss mehrere Dimensionen decken: rechtlich, technisch, operationell und finanziell. Diese Bewertung muss dokumentiert und periodisch aktualisiert werden.

Analyse der anwendbaren Jurisdiktion

Die Jurisdiktion der vertragschliessenden Entität und der Mutter identifizieren. Ein Schweizer Provider, dessen Mutter US ist, kann unter dem CLOUD Act bleiben. Das Fehlen rechtlicher Bindungen an Risikojurisdiktionen prüfen.

AGB prüfen, um Gerichtsstands- und Rechtswahlklauseln zu identifizieren. Schweizer Recht und einen Gerichtsstand in der Schweiz für Streitigkeiten bevorzugen. Hikube betreibt Hidora SA unter Schweizer Recht.

Prüfung der physischen Infrastruktur

Den realen Standort der genutzten Rechenzentren auditen. Einige Provider bieten Standortoptionen, nutzen aber geteilte Infrastruktur mit internationaler Replikation als Default.

Zertifizierungen der Rechenzentren (ISO 27001, SOC 2) und ihren genauen Scope prüfen. Eine Zertifizierung des Sitzes impliziert keine Zertifizierung der Rechenzentren. Hikube-ISO-27001 ist von SQS auf dem publizierten Scope ausgestellt.

Bewertung der Sicherheitsreife

Die Sicherheitspraktiken des Providers analysieren: Zugriffsverwaltung, Verschlüsselung, Monitoring, Incident Response. Greifbare Beweise verlangen (Auditberichte, Zertifizierungen) statt Erklärungen.

Die Transparenz des Providers zu staatlichen Zugriffsanfragen bewerten. Einige Provider publizieren Transparenzberichte; andere verweigern die Kommunikation zu diesem Thema.

Finanzielle Stabilität und Dauerhaftigkeit

Die finanzielle Solidität des Providers bewerten. Ein Providerausfall kann Kontinuitäts- und Compliance-Risiken erzeugen, wenn Daten unerreichbar werden oder vertragliche Dokumentation verloren geht.

Provider mit nachgewiesener Historie und etablierter Kundenbasis in regulierten Sektoren bevorzugen. Keine Kundenzahlen als Hikube-Ansprüche erfinden.

Welche operationellen Kontrollen auf einer souveränen Cloud einrichten?

Operationelle Kontrollen übersetzen Compliance-Anforderungen in die tägliche Praxis. Sie sollten so weit wie möglich automatisiert werden, um systematische Anwendung zu garantieren.

Identitäts- und Zugriffsverwaltung

Rollenbasierte Zugriffskontrolle (RBAC) mit Least Privilege implementieren. Zugriffsrechte auf Cloud-Umgebungen dokumentieren und regelmässig auditen.

Multifaktor-Authentifizierung für alle administrativen Zugriffe einschalten. Identitätsverwaltung über einen kompatiblen Identity Provider (SAML, OIDC) zentralisieren, um eine einheitliche Sicht zu halten.

Verschlüsselung und Schlüsselverwaltung

Daten at rest und in Transit verschlüsseln. Für sensible Daten organisationsverwaltete Schlüssel (Customer-Managed Keys) nutzen, wo das Produkt es erlaubt. Schlüsselrotations- und Recovery-Verfahren dokumentieren.

Die Schlüsselnutzung regelmässig auditen, um abnorme Zugriffe zu erkennen. Hardware-Security-Module (HSM) bieten Extra-Garantien für die kritischsten Schlüssel. Kein Hikube-HSM-SKU erfinden, wenn es nicht im Katalog steht.

Protokollierung und Nachvollziehbarkeit

Exhaustive Protokollierung von Zugriffen und Änderungen auf Cloud-Ressourcen einschalten. Logs in unveränderlichem Storage halten, um ihre Integrität beim Audit zu garantieren.

Aufbewahrungsdauern definieren, die zu den regulatorischen Anforderungen passen. FINMA-Institute müssen bestimmte Logs 10 Jahre halten. Das ist eine regulatorische Pflicht des Instituts, kein veröffentlichter Hikube-Retention-Kredit.

Erkennung und Incident Response

Erkennung von Anomalien und verdächtigem Verhalten deployen. Dokumentierte und getestete Incident-Response-Verfahren definieren.

Cloud-Alerts in den globalen Security-Incident-Prozess integrieren. Eskalationsschwellen zum Supervisor oder zu zuständigen Behörden dokumentieren.

Wie Hikube Schweizer Compliance-Anforderungen beantwortet

Hikube ist eine souveräne Cloud-Plattform, ausgelegt für regulierte Organisationen in der Schweiz. Ihre Architektur und ihr Betriebsmodell integrieren Compliance-Kontrollen. Sie stützt Ihr Dossier; sie zertifiziert nDSG oder FINMA nicht.

Infrastruktur in der Schweiz ohne extraterritoriale Mutter

Hikube operiert ausschliesslich auf drei Rechenzentren in der Schweiz (Gland, Luzern, Genf). Das Unternehmen ist schweizerischen Rechts (Hidora SA), ohne US-Mutter. Diese Rechtsstruktur bedeutet, dass es nicht unter dem CLOUD Act oder einem gleichwertigen extraterritorialen Gesetz steht, wie eine US-kontrollierte Gruppe.

Daten können über die drei Sites im Volume-Replikationsmodus repliziert werden, den Sie wählen, mit Ziel hoher Verfügbarkeit (Hikube publiziert 99,99 % auf gelisteten Produkten) ohne Transfer ausserhalb der Schweiz. Dieser Artikel erfindet keine Extra-SLA-Kredite.

Integrierte regulatorische Unterstützung

Hikube/Hidora ist von SQS nach ISO 27001 zertifiziert. Zertifikat und exakter Scope sind bei einem Ingenieur zu beziehen: das PDF ist nicht publiziert, und dieser Artikel leitet daraus keinen Scope ab. Nachweise: Sicherheit und Compliance. Managed Databases und Storage enthalten Verschlüsselung als Default, wie publiziert.

Regulierte Kunden können ein Data Processing Agreement (DPA) erhalten, ausgerichtet an nDSG und DSGVO. Ein Auszug des Bearbeitungsregisters kann auf Anfrage geliefert werden, um Compliance-Audits zu erleichtern. Hikube zertifiziert Ihr Dossier nicht. Kein ISO-27018-Anspruch. Kein französisches HDS.

Offene Standards und Reversibilität

Hikube nutzt Standardtechnologien: CNCF-zertifiziertes Kubernetes (hosted, Talos-Worker, Cilium, KCSP), S3-kompatibler Storage, dokumentierte REST-APIs. Dieser Ansatz stützt Workload-Portabilität und senkt Lock-in. Keine Kubernetes-Versionspin erfinden.

Technische Teams können ihre üblichen Werkzeuge nutzen (kubectl, Terraform, Helm, Flux CD) ohne Anpassung. Eine Migration von oder zu Hikube braucht keine Anwendungsneuschreibung.

Isolation und Kundenkontrolle

Jeder Kunde hat einen isolierten Tenant mit Trennung von Netz, Storage und Identität. Diese Isolation vermeidet Interferenzen zwischen Kunden und erleichtert Scope-Audits.

Der Monitoring-Stack, den Sie betreiben, bleibt im Kundentenant. Metriken und Logs bleiben unter ausschliesslicher Kontrolle des Kunden, ohne Sharing mit anderen Tenants. Support auf Französisch und Englisch, kein deutscher Support.

Fazit: wie Cloud-Compliance in der Schweiz gelingt

Public-Cloud-Compliance in der Schweiz ruht auf einem strukturierten Ansatz, der regulatorische Analyse, technische Architektur und operationelle Kontrollen kombiniert. Regulierte Organisationen müssen jeden Cloud-Provider auf Jurisdiktion, Zertifizierungen und Sicherheitspraktiken bewerten.

Die Hauptrisiken sind extraterritorialer Datenzugriff (CLOUD Act), das Fehlen einer Datenflusskarte und vertragliche Lücken. Diese Risiken können durch die Wahl eines souveränen Providers, offene Standards und nachprüfbare technische Kontrollen gemildert werden.

Das Ziel: ein Entscheidungsrahmen, der IT-Entscheidern erlaubt, Cloud-Dienste zu wählen und zu betreiben und dabei die Schweizer regulatorischen Anforderungen einzuhalten. Siehe nDSG-Pflichten und Sicherheit und Compliance.

FAQ zur Public-Cloud-Compliance in der Schweiz

Gilt der US CLOUD Act für in der Schweiz gespeicherte Daten?

Der CLOUD Act gilt für jede Entität unter US-Jurisdiktion, unabhängig vom Serverstandort. AWS, Azure und GCP können gezwungen werden, in der Schweiz gespeicherte Daten an US-Behörden herauszugeben. Hikube, als Gesellschaft schweizerischen Rechts ohne US-Kapitalbindung, steht nicht unter dem CLOUD Act. Schweizer Rechtshilfe existiert weiter: ein Schweizer Betreiber heisst nicht, dass nie eine Behörde Daten erhalten kann.

Welche Zertifizierungen muss ein Cloud-Provider für den Schweizer Finanzsektor haben?

Die FINMA schreibt keine spezifische Zertifizierung vor, verlangt aber, dass das Finanzinstitut seinen Provider auditen kann. ISO 27001 und SOC 2 Type II sind anerkannte Belege für Sicherheitsreife. Hikube/Hidora hält ISO 27001, ausgestellt durch SQS; der Scope ist auf Anfrage verfügbar. Es beansprucht kein SOC 2. Es zertifiziert Ihr FINMA-Dossier nicht.

Wie nDSG-Konformität bei einem Cloud-Deployment garantieren?

nDSG-Konformität für Cloud ruht auf drei Säulen: Datenstandort in einem Land mit angemessenem Schutzniveau, ein Auftragsbearbeitungsvertrag ausgerichtet an nDSG Art. 9, und angemessene technische Massnahmen. Die Wahl eines ausschliesslich schweizerischen Providers wie Hikube vereinfacht diesen Nachweis. Sie ersetzt Ihr Dossier nicht.

Was sind die Cloud-Nichtkonformitätsrisiken für ein FINMA-Institut?

Finanzinstitute setzen sich administrativen Massnahmen aus, die bis zum Entzug der Bewilligung gehen können. Verantwortliche Personen können individuellen Sanktionen einschliesslich Bussen und Berufsverboten gegenüberstehen. Ein Bruch des Bankgeheimnisses (Art. 47 BankG) ist eine Straftat, die Gefängnis nach sich ziehen kann. Keine Rechtsberatung.

Wie ein FINMA-Audit zur Cloud-Nutzung vorbereiten?

Cloud-Verträge, Risikoanalysen und Kontrollen exhaustiv dokumentieren. Eine aktuelle Karte der Daten und ihres Standorts halten. Auditbelege vorbereiten (SOC-2-Berichte, wenn Sie sie haben, Zertifizierungen) und Incident-Management-Verfahren. Hikube liefert auf Anfrage die für regulatorische Audits nötige Dokumentation. Das Audit führen Sie.

GPU-Katalogkarten in der 14-Tage-Trial, wenn regulierte Workloads sie brauchen: L4, L40S, A100-80, RTX 6000 Pro, H100, H200. Windows ist kein Katalogprodukt. Hikube berechnet Egress im TCO-Vergleich nicht. Mit dem Team sprechen.