Ausschreibung Verschlüsselung (2026): Anforderungskatalog und Checkliste für kundenkontrollierte Schlüssel

Diese Vorlage für eine Ausschreibung Verschlüsselung ist ein herstellerneutraler Anforderungskatalog (Verschlüsselung) für den Schutz ruhender Daten in Cloud, SaaS und Datenbanken mit Schlüsseln, die Sie selbst kontrollieren. Sie umfasst elf Anforderungsgruppen (Umfang, Verschlüsselungsmodelle, Schlüsselkontrolle und Souveränität, Plattformintegrationen, Verfügbarkeit, Kryptografie, Zugriffsrichtlinien, Audit, regulatorische Zuordnung, Betrieb und Exit, Anbieter und Support), ein gewichtetes Bewertungsmodell, 20 Anbieterfragen, Warnsignale, einen PoC-Plan und Vertragsklauseln. Alle Tabellen lassen sich in eine Tabellenkalkulation kopieren.

---

Inhaltsverzeichnis

1. Für wen und wie Sie die Vorlage nutzen
2. Bevor Sie die Ausschreibung schreiben
3. Anforderungskatalog
4. Gewichtetes Bewertungsmodell
5. 20 Fragen an die Anbieter
6. Warnsignale in Anbieterantworten
7. Proof-of-Concept-Plan
8. Vertrags- und Exit-Klauseln
9. Einleitungstext zum Kopieren
10. FAQ
11. Fazit
12. Quellen

---

Für wen und wie Sie die Vorlage nutzen

Die Vorlage richtet sich an Sicherheitsarchitekten, CISOs, Datenschutzbeauftragte, Einkauf und Verantwortliche für Cloud-Plattformen, die eine Lösung zur Verschlüsselung von Unternehmensdaten beschaffen oder neu ausschreiben müssen, bei der der Kunde und nicht der Cloud- oder SaaS-Anbieter die Schlüssel kontrolliert. Sie gilt unabhängig davon, ob das Ergebnis BYOK, HYOK, externes Schlüsselmanagement (EKM), Double Key Encryption (DKE), clientseitige Verschlüsselung, Tokenisierung oder Feldverschlüsselung heisst.

So gehen Sie vor:

1. Kopieren Sie den Einleitungstext am Ende in Ihre Ausschreibung und passen Sie den Umfang an.
2. Fügen Sie die Anforderungstabellen in eine Tabellenkalkulation ein. Behalten Sie die ID-Spalte: Sie ermöglicht Bewertung und Nachweisverfolgung.
3. Streichen Sie nicht relevante Anforderungen (zum Beispiel Salesforce, wenn Sie es nicht nutzen) und passen Sie die Gewichtung an.
4. Verlangen Sie Nachweise statt Behauptungen. Jede Zeile nennt den Nachweis.

Prioritäten: Muss (Ausschlusskriterium), Soll (wird bewertet, eine Lücke ist mit Plan akzeptabel) und Erweitert (differenzierende Fähigkeiten, die manche Produkte bieten und die Sie nur verpflichtend machen sollten, wenn Ihr Risikomodell es verlangt).

Diese Seite ist eine Beschaffungshilfe und keine Rechtsberatung. Lassen Sie die regulatorischen Bezüge von Ihrer Rechtsabteilung prüfen.

---

Bevor Sie die Ausschreibung schreiben

Die meisten Verschlüsselungsprojekte scheitern vor der Ausschreibung, nämlich am Umfang. Klären Sie fünf Punkte zuerst.

1. Daten inventarisieren und klassifizieren. Listen Sie die Plattformen mit regulierten oder vertraulichen Daten auf: Microsoft 365 (Exchange, SharePoint, OneDrive, Teams), Salesforce, ServiceNow, AWS-Speicher und -Datenbanken, Azure, SQL Server, Oracle, Snowflake, Databricks und KI-Dienste wie OpenAI. Ordnen Sie jeder eine Klassifizierung zu und notieren Sie Volumen und Residenzvorgaben.

2. Bedrohung festlegen.

3. Modell pro Workload festlegen. Ein einziges Modell passt selten zu allen Plattformen. Siehe Hold Your Own Key (HYOK) und BYOK erklärt.

4. Stakeholder benennen. Sicherheitsarchitektur, Plattformverantwortliche, Applikationsverantwortliche, Datenschutz oder Recht, Betrieb/SRE (sie betreiben den Schlüsseldienst), Einkauf und Interne Revision.

5. Kriterien und Gewichte festlegen, bevor Sie eine Antwort lesen.

---

Anforderungskatalog

Jede Gruppe ist eine Tabelle mit ID, Anforderung, Priorität und Nachweis. Die Anforderungen sind so formuliert, dass ein ernstzunehmendes Produkt der Kategorie sie erfüllen und belegen kann.

Gruppe 1. Umfang und Datenklassifizierung

Gruppe 2. Verschlüsselungsmodelle

Gruppe 3. Schlüsselkontrolle und Souveränität

Gruppe 4. Plattformintegrationen

Behalten Sie nur die benötigten Zeilen. «Unterstützt» heisst dokumentiert, gegen aktuelle Plattformversionen getestet und vom Anbieter unterstützt, nicht «mit Eigenentwicklung möglich».

Gruppe 5. Performance und Verfügbarkeit

Ein externer Schlüsseldienst legt Ihren Schlüsselmanager auf den kritischen Pfad Ihrer Cloud-Daten. Diese Gruppe wird am häufigsten zu knapp spezifiziert.

Gruppe 6. Kryptografie und Post-Quanten-Bereitschaft

Gruppe 7. Zugriffsrichtlinien

Gruppe 8. Audit und Monitoring

Gruppe 9. Regulatorische Zuordnung

Lassen Sie den Anbieter seine Fähigkeiten in eigenen Worten den für Sie geltenden Regeln zuordnen. Akzeptieren Sie keine blosse Logoliste. Die Bezüge sind generische Ankerpunkte, keine Konformitätsbehauptung.

Gruppe 10. Betrieb und Exit/Portabilität

Gruppe 11. Anbieter und Support

---

Gewichtetes Bewertungsmodell

Die Gewichte sollten Ihr Risikomodell abbilden. Die Tabelle ist ein Beispiel mit frei erfundenen, generischen Zahlen.

Skala von 0 bis 5 je Anforderung:

Wenden Sie zuerst ein Ausschlusskriterium an: Jede Muss-Anforderung mit 0 oder 1 schliesst aus oder verlangt vor der Shortlist eine schriftliche Nachbesserung.

Rechenbeispiel (rein illustrative Zahlen). Anbieter A erreicht im Schnitt 4,0 bei Schlüsselkontrolle, 3,5 bei Integrationen, 3,0 bei Verfügbarkeit, 4,0 bei Audit, 3,0 bei Kryptografie, 4,0 bei Regulatorik, 3,0 bei Betrieb und Exit, 3,5 beim Anbieter. Gewichtet: 0,20 x 4,0 + 0,20 x 3,5 + 0,15 x 3,0 + 0,10 x 4,0 + 0,05 x 3,0 + 0,10 x 4,0 + 0,10 x 3,0 + 0,10 x 3,5 = 0,80 + 0,70 + 0,45 + 0,40 + 0,15 + 0,40 + 0,30 + 0,35 = 3,55 von 5. Vergleichen Sie den Wert mit anderen, gleich bewerteten Anbietern und mit den Kosten über fünf Jahre.

---

20 Fragen an die Anbieter

1. Welches Verschlüsselungsmodell liefern Sie tatsächlich je Plattform in unserem Umfang (Anbieterschlüssel, BYOK, HYOK/EKM, clientseitig)?
2. Wo findet die kryptografische Operation beim Entschlüsseln statt: bei Ihnen oder beim Cloud-Anbieter mit einem Schlüssel, den Sie ihm gegeben haben?
3. Wer in Ihrer Organisation und Hosting-Kette kann Schlüsseloperationen auslösen oder einsehen? Unter welchen Kontrollen?
4. In welcher Rechtshoheit wird der Schlüsseldienst gehostet und betrieben? Welche Behörden könnten Sie oder Ihren Hoster verpflichten?
5. Was passiert mit unseren Daten, wenn der Schlüsseldienst nicht erreichbar ist, je Plattform? Ist es fail-closed, und wie lange funktionieren Caches?
6. Wie viel Latenz fügt eine Schlüsseloperation hinzu, und wie lauten die Timeouts der jeweiligen Plattformen?
7. Zeigen Sie Ihre hochverfügbarste Referenzarchitektur und Ihren letzten Failover-Test.
8. Welche RPO und RTO gelten für den Schlüsseldienst selbst?
9. Wie entziehen wir der Plattform den Zugriff, und wie lange dauert es gemessen, bis die Daten unzugänglich sind?
10. Wie werden Schlüssel rotiert, und erfordert die Rotation eine Neuverschlüsselung der Daten?
11. Welche HSM oder Gleichwertiges sichern die Wurzelschlüssel, mit welchen Zertifizierungen?
12. Wie wird der Administratorzugriff authentifiziert, und können wir Freigaben durch mehrere Personen verlangen?
13. Was wird protokolliert, wohin lässt es sich exportieren, und wie prüfen wir, dass Logs nicht verändert wurden?
14. Was geschieht, wenn ein Audit-Eintrag nicht geschrieben werden kann?
15. Gegen welche unserer Vorschriften (DSGVO, DSG, DORA, NIS2, FINMA, HIPAA) wurden Sie von Kunden oder Prüfern beurteilt, und was liefern Sie für Audits?
16. Wie sieht Ihre Post-Quanten-Roadmap mit Terminen für Schlüsselumhüllung und Signaturen aus?
17. Welche Teile der Lösung sind Eigenentwicklung, welche Drittanbieter- oder Open-Source-Komponenten?
18. Beschreiben Sie den Exit: Wie verlassen wir Sie in 90 Tagen mit allen lesbaren Daten?
19. Welche bekannten Einschränkungen hat jede Plattformintegration (Funktionen, die mit kundengehaltenen Schlüsseln entfallen)?
20. Welche Kunden aus unserer Branche betreiben das produktiv, und seit wann?

---

Warnsignale in Anbieterantworten

• «Im Ruhezustand verschlüsselt» als einzige Antwort: Das ist anbieterverwaltete Verschlüsselung und sagt nichts über Schlüsselkontrolle.
• Keine schriftliche Aussage dazu, wer auf Schlüssel zugreifen kann, oder eine Antwort, die auf «Vertrauen» beruht.
• BYOK, das als HYOK verkauft wird. Hält der Anbieter am Ende eine nutzbare Kopie des Schlüssels, ist es kein HYOK.
• Fail-open als Feature, ohne Erklärung, was das für die gekaufte Kontrolle bedeutet.
• Keine Latenz- oder Kapazitätswerte für die für Sie wichtigste Plattform.
• Hochverfügbarkeit als «Cloud-nativ» beschrieben, ohne Failover-Test.
• Exit-Plan lautet «wenden Sie sich an den Support».
• Compliance als Liste von Vorschriften ohne Zuordnung zu Fähigkeiten.
• «Post-Quanten-ready» ohne benannte Algorithmen oder Termine.
• Referenzen, die man nicht anrufen kann.

---

Proof-of-Concept-Plan

Führen Sie den PoC auf den zwei bis drei Plattformen mit dem höchsten Risiko durch. Legen Sie Bestehens-Kriterien vor Beginn fest.

---

Vertrags- und Exit-Klauseln

• Eigentum an Daten und Schlüsseln. Schlüssel, Schlüsselmetadaten und Audit-Logs gehören dem Kunden.
• Rechtshoheit und Zugriff. Hosting-Standort, Einheiten mit möglichem Zugriff, Pflicht zur Information des Kunden über Rechtsersuchen, soweit gesetzlich zulässig.
• Unterauftragnehmer. Liste, Benachrichtigung bei Änderungen, Widerspruchsrecht.
• Verfügbarkeit. SLA mit Gutschriften, definiertes Fail-closed- oder Fail-open-Verhalten, Wartungsfenster.
• Sicherheit. Fristen zur Schwachstellenmeldung, Meldefrist bei Sicherheitsvorfällen, Prüf- und Inspektionsrechte.
• Regulatorik. Klauseln für die anwendbaren Rahmenwerke (zum Beispiel DORA-Vertragsbestimmungen für IKT-Drittdienstleistungen).
• Exit. Unterstützung, Exportformate, Übergangsfrist, Preis der Exit-Leistungen, Löschbestätigungen.
• Escrow oder Fortführung, wenn der Schlüsseldienst kritisch ist.
• Ordentliche Kündigung oder Kündigung bei regulatorischer Änderung.

---

Einleitungstext zum Kopieren

[Unternehmen] schreibt eine Lösung zur Verschlüsselung von Unternehmensdaten aus, die ruhende Daten in [Liste der Plattformen: zum Beispiel Microsoft 365, Salesforce, ServiceNow, AWS, Azure, SQL Server, Oracle, Snowflake, Databricks und KI-Diensten] mit kryptografischen Schlüsseln schützt, die unter der Kontrolle von [Unternehmen] bleiben. Die Lösung muss es [Unternehmen] ermöglichen, zu bestimmen, wer Schlüssel nutzen und widerrufen kann, das Verhalten jeder Plattform bei Nichtverfügbarkeit des Schlüsseldienstes zu dokumentieren, Audit-Nachweise für [anwendbare Vorschriften: DSGVO, DSG, DORA, NIS2, FINMA, HIPAA] bereitzustellen und einen dokumentierten Exit-Pfad zu bieten. Anbieter füllen die Anforderungstabellen in Anhang B aus, nennen ihre Annahmen je Plattform und belegen jede Muss-Anforderung. Die Bewertung erfolgt nach dem gewichteten Modell in Anhang C; Anbieter der engeren Wahl nehmen an einem Proof of Concept mit Bestehens-Kriterien teil.

---

FAQ

Was gehört in eine Ausschreibung zur Verschlüsselung?

Umfang und Klassifizierung, Verschlüsselungsmodelle je Plattform, Schlüsselkontrolle und Rechtshoheit, Integrationen, Verhalten bei Ausfall, Kryptografie, Zugriffsrichtlinien, Audit, regulatorische Zuordnung, Betrieb und Exit sowie Support. Ergänzen Sie ein Bewertungsmodell und einen PoC. Die Checkliste oben liefert dies als kopierbare Tabellen.

Worin unterscheiden sich BYOK und HYOK in der Ausschreibung?

Bei BYOK erzeugen oder importieren Sie einen Schlüssel, den der Anbieter anschliessend hält und nutzt. Bei HYOK oder externem Schlüsselmanagement bleibt der Schlüssel in Ihrem Schlüsselmanager, und der Anbieter ruft ihn für jede Operation auf. Verlangen Sie, dass der Anbieter das Modell je Plattform nennt, und lesen Sie BYOK erklärt.

Sollten wir Fail-closed-Verhalten verlangen?

Für regulierte Daten ist Fail-closed meist gewünscht: Ist der Schlüsseldienst nicht erreichbar oder verweigert er, bleiben die Daten unzugänglich. Dafür wird Ihr Schlüsseldienst zur kritischen Infrastruktur. Verlangen Sie Hochverfügbarkeit, Ausfalltests und dokumentiertes Cache-Verhalten je Plattform, und entscheiden Sie fail-closed oder fail-open je Workload.

Brauchen wir clientseitige Verschlüsselung oder Double Key Encryption?

Nicht für jede Workload. Double Key Encryption, etwa DKE in Microsoft 365, ist für eine kleine Menge hochsensibler Inhalte gedacht, weil Funktionen wie die serverseitige Suche bei geschützten Inhalten eingeschränkt sind. Nutzen Sie externes Schlüsselmanagement für die Breite und Double Key oder clientseitige Verschlüsselung für die kritischsten Daten. Siehe die DKE-Einrichtungsanleitung.

Wie vergleichen wir HSM-basierte und softwarebasierte oder Mehrparteien-Schlüsseldienste?

Vergleichen Sie sie anhand derselben Anforderungen: Wer kann auf Schlüssel zugreifen, Zertifizierungen, Verfügbarkeit, Performance, Audit und Exit. Schliessen Sie keine Kategorie pauschal aus, sofern Ihre Vorschrift es nicht verlangt. Die KMS-Ausschreibungsvorlage behandelt Schlüsselmanagement-Produkte ausführlicher.

Wie behandeln wir Post-Quanten-Kryptografie in der Ausschreibung?

Als Anforderung an Roadmap und Krypto-Agilität: Welche Algorithmen aus FIPS 203, 204 und 205 werden wann unterstützt, und wie werden Algorithmen gewechselt. Siehe die Post-Quanten-Ausschreibungsvorlage.

Ist ein Anbieter ausserhalb der EU oder der Schweiz akzeptabel?

Das hängt von Ihrer Risikobeurteilung, den Daten und Ihrer Aufsicht ab. Entscheidend ist, wer unter welcher Rechtsordnung auf Schlüssel zugreifen kann. Fragen Sie nach der Rechtshoheit von Anbieter und Hosting-Einheit und lesen Sie Datensouveränität und Verschlüsselungsschlüssel.

---

Fazit

Eine gute Ausschreibung zur Verschlüsselung prüft Kontrolle, nicht Funktionsumfang. Fragen Sie, wer die Schlüssel zur Laufzeit hält, was bei Ausfall des Schlüsseldienstes passiert, wie Sie widerrufen, wie Sie es einem Prüfer belegen und wie Sie wieder wechseln. Bewerten Sie alle Anbieter mit denselben Gewichten und validieren Sie im PoC. DuoKey bietet Management kundenkontrollierter Schlüssel für die genannten Plattformen; Vergleichsseiten finden Sie zu Thales, Fortanix und Entrust. Berücksichtigen Sie DuoKey wie jeden anderen Anbieter nur aufgrund von Nachweisen.

---

Quellen

• AWS KMS developer guide, External key stores: https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html
• Microsoft Learn, Double Key Encryption: https://learn.microsoft.com/en-us/purview/double-key-encryption
• Verordnung (EU) 2016/679 (DSGVO): https://eur-lex.europa.eu/eli/reg/2016/679/oj
• Verordnung (EU) 2022/2554 (DORA): https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• Richtlinie (EU) 2022/2555 (NIS2): https://eur-lex.europa.eu/eli/dir/2022/2555/oj
• Schweizer Datenschutzgesetz (DSG): https://www.fedlex.admin.ch/eli/cc/2022/491/de
• FINMA-Rundschreiben 2023/1 Operationelle Risiken und Resilienz: https://www.finma.ch
• HIPAA Security Rule, 45 CFR 164.312: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C
• NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
• NIST FIPS 203, 204, 205: https://csrc.nist.gov/projects/post-quantum-cryptography
• DuoKey-Dokumentation, OpenAI EKM: https://docs.duokey.com/docs/openai-ekm/overview
• DuoKey-Dokumentation, Salesforce EKM: https://docs.duokey.com/docs/salesforce-byok/ekm-module
• DuoKey-Dokumentation, SQL EKM: https://docs.duokey.com/docs/sql-ekm/overview
• DuoKey-Dokumentation, Cockpit Sicherheit und Audit: https://docs.duokey.com/docs/cockpit/security