Die Crypto Valley Association (CVA) hat Ende Mai 2026 die erste Ausgabe ihres «Cyber Framework for Startups» publiziert. 13 Praktiker aus Security, Kryptografie, Recht und Compliance haben darin auf 165 Seiten zusammengetragen, was ein zweiköpfiges Team ab Tag eins umsetzen kann – und was es später braucht, wenn aus dem Startup ein regulierter Anbieter wird.
Das Problem: Bankenrisiko mit Startup-Ressourcen
Das Vorwort von Markus Perdrizat, Chairman der CVA Cybersecurity Working Group, kommt ohne Beschönigung aus: In den letzten zwei Jahren wurde praktisch jeder Teil der Branche getroffen – zentralisierte Börsen mit Milliarden-Treasuries, mehrfach auditierte DeFi-Protokolle, Open-Source-Maintainer, deren stille Projekte Millionen von Nutzern betreffen. Die Angreifer reichen von staatlich gesponserten Gruppen über organisierte Kriminalität bis zu Gelegenheitstätern mit Standard-Tools.
Krypto-Startups tragen dabei ein besonders ungünstiges Risikoprofil:
- Treasury-Bestände, die schnell die Grössenordnung mittlerer Fonds erreichen
- Code, der öffentlich und unveränderlich deployt wird
- Regulatorische Erwartungen, die an Banken angelehnt sind
Die etablierten Frameworks – NIST CSF, ISO 27001, SOC 2, CIS Controls – sind für Organisationen mit Security-Abteilung, Budget und Planungshorizont geschrieben. Ein Team von drei bis fünfzehn Leuten mit begrenztem Runway und einer Deadline kann sie schlicht nicht stemmen. Dazu kommt: Genau die Risiken, welche die Branche definieren – Private Keys, Smart Contracts, On-Chain-Finalität, öffentlich sichtbare Exploit-Anreize – liegen fast vollständig ausserhalb dieser Allzweck-Standards.
Perdrizats Kernargument: Wenn Product-Market-Fit einmal da ist, muss es schnell gehen. Sind die Fundamente zu diesem Zeitpunkt falsch gelegt, ist Nachrüsten extrem teuer bis unmöglich. Mit den kommenden KI-Modellen verkürze sich zudem die Zeitspanne zwischen erfolgreichem Launch und erstem grossen Hack für alle, die nicht vorbereitet sind.
Der Ansatz: Crawl, Walk, Run
Das Framework sortiert jede Massnahme in eine von drei Reifestufen. Das ist der eigentliche Kniff des Dokuments – man arbeitet nicht eine Liste von 400 Kontrollen ab, sondern beginnt mit den Punkten der eigenen Stufe.
| Stufe | Bedeutung | Anspruch |
|---|---|---|
| Crawl | Getting Started | Die 20 % der Massnahmen, die 80 % der Breaches verhindern. Wer sie überspringt, wird gehackt. |
| Walk | Building Resilience | Wiederholbare Prozesse, die den Weggang einzelner Personen überleben. Pflicht, sobald Nutzer oder Assets im Spiel sind. |
| Run | Institutional Grade | Auditierbare Defense-in-Depth, tauglich für regulierte Umgebungen und Counterparty-Due-Diligence. |
Zwei Präzisierungen sind wichtig: Die Stufen sind kumulativ, und sie hängen nicht an der Teamgrösse. Ein Vierpersonen-Team, das reguliertes Custody betreibt, gehört ab Tag eins auf Walk oder Run. Und die Einstufung erfolgt pro Kapitel – ein Startup kann bei Key Management legitim auf Walk stehen und bei Developer Security auf Crawl.
Die 17 Kapitel im Überblick
Jedes Kapitel beginnt mit einem «Why this matters» für den Founder und einem «What you need to do» für die ausführende Person, gefolgt von Checklisten nach Reifestufe.
Governance und Organisation (Kap. 1–6) Information Security Governance, Compliance und regulatorische Pflichten, Risk Management, Third-Party- und Dependency-Risiken, Resilienz und Business Continuity, Datenschutz und Zugriffskontrolle.
Bauen und Betreiben (Kap. 7–9) Development und DevSecOps, Monitoring und Incident Management, People und Security Awareness.
Krypto-spezifische Kontrollen (Kap. 10–14) Key Management und Custody, sichere Custody- und Transaktionskontrollen, Krypto-Infrastruktursicherheit, Smart-Contract-Sicherheit, Application- und Exchange-Layer-Sicherheit.
Aktive Verteidigung und KI (Kap. 15–17) KI-gestützte Cyber-Defense in Web3, blockchain-spezifisches Testing sowie Red-/Blue-Team-Übungen, und schliesslich KI und agentische KI in Blockchain und Web3.
Dazu kommen Anhänge zu Third-Party-Typen, Custody-Modellen, Incident-Playbooks, referenzierten Standards und ein Glossar.
Wie konkret wird es? Beispiel Key Management
Kapitel 10 illustriert den Detailgrad gut. Die Crawl-Stufe verlangt unter anderem:
- Keys ausschliesslich mit kryptografisch sicheren Tools und NIST/FIPS-konformen Algorithmen erzeugen – nie in ungesicherten Umgebungen, Browser-Extensions oder auf geteilten Rechnern
- Private Keys und Seed Phrases niemals im Klartext ablegen: nicht in Repos, Config-Files, E-Mails, Cloud-Drives oder Messengern
- Hardware-Wallets oder passwortverschlüsselte Keystores für alle Produktions-Keys
- Sicherstellen, dass im Notfall mindestens zwei autorisierte Personen an kritisches Key-Material kommen
- Eine simple Revocation-Prozedur: Bei Kompromittierung oder Abgang einer Person mit Key-Zugriff sofort widerrufen, dokumentieren und abhängige Keys rotieren
- Ein einfaches Key-Inventar: Welches Wallet, wer kontrolliert es, wo liegt das Backup
Auf Walk kommen dokumentierter Lifecycle, Mehr-Augen-Prinzip für sämtliche Key-Operationen, verschlüsselte Offline-Backups an mindestens zwei physisch getrennten Orten und getestete Recovery-Verfahren dazu. Run bedeutet HSM- oder MPC-Infrastruktur mit manipulationssicherem Audit-Trail.
Die Diagnose des Kapitels ist bemerkenswert nüchtern: Praktisch jeder grosse Verlust der Branche lässt sich auf eine von drei Ursachen zurückführen – ein Key im Klartext, ein Treasury konzentriert in einem Hot Wallet, oder eine einzelne Person mit alleiniger Signaturbefugnis.
Regulatorischer Bezug: MiCAR, DORA, FINMA
Für Schweizer Leser besonders relevant ist Kapitel 2. Das Framework ordnet die Pflichten entlang dreier Blöcke: EU/UK/Schweiz, USA und Asien-Pazifik.
Europa gilt dabei als der am weitesten kodifizierte Raum: Wer in der EU tätig ist oder EU-Nutzer bedient, fällt unter MiCAR und DORA. Die Schweiz erreicht über ihre technologieneutrale Finanzmarktgesetzgebung ein vergleichbares Niveau, ergänzt um die operationellen Resilienzanforderungen der FINMA – namentlich das FINMA-Rundschreiben 2023/01 zu Operational Risk und Resilienz. Die Regime konvergieren laut Framework bei ICT-Risikomanagement, Incident-Reporting, Resilienz-Testing, Third-Party-Aufsicht und dokumentierter Governance.
Explizit erwähnt: Die Checklisten sind allgemeine Orientierung und ersetzen keine Rechtsberatung.
Für wen das Dokument gedacht ist
Primäradressat ist die «Security-Responsible Person» im Startup – auf dieser Stufe fast nie ein CISO, sondern in aller Regel CEO oder CTO. Das «Warum» richtet sich an Gründer, das «Was» an die Umsetzenden.
Daneben sieht die CVA das Framework als Werkzeug für Investoren, Auditoren und Berater, die Frühphasen-Unternehmen im Digital-Asset-Bereich beurteilen. Die Reifestufen liefern dafür ein gemeinsames Vokabular und beantworten die Frage, wo ein Startup in seiner jeweiligen Wachstumsphase idealerweise stehen sollte.
Was es nicht ist
Das Dokument grenzt sich selbst deutlich ab:
- Keine Rechts-, Regulierungs- oder Finanzberatung – jurisdiktionsspezifische Pflichten gehören zu qualifiziertem Rechtsbeistand.
- Kein Ersatz für professionelle Security-Arbeit bei Skalierung – externe Audits und eine dedizierte Security-Funktion werden auf Walk und Run unumgänglich.
- Keine Zertifizierung – wer das Framework umsetzt, erhält kein Attestat. Es soll aber den Weg zu ISO 27001, SOC 2 oder einer Lizenzierung spürbar erleichtern.
- Kein statisches Dokument – geplant ist eine jährliche Aktualisierung, bei materiellen Änderungen der Bedrohungs- oder Regulierungslage auch früher.
Hintergrund und Bezug
Verfasst wurde das Framework von 13 Praktikern – Security Engineers, Kryptografen, Juristinnen, Risiko- und Compliance-Spezialisten – mit Erfahrung bei Krypto-Börsen, Custodians, Infrastrukturanbietern und regulierten Finanzinstituten. Projektleitung und redaktionelle Koordination lagen bei Markus Perdrizat (ACK, Chair der CVA Cybersecurity Working Group), das Projektmanagement und Lektorat bei Euodia Guthrie.
Edition 1.0, publiziert am 28. Mai 2026. Feedback und Ergänzungsvorschläge nimmt die Working Group entgegen; erreichbar ist sie über die Seite der CVA Cybersecurity Working Group.
Einordnung
Der praktische Wert liegt weniger in einzelnen Kontrollen – vieles davon findet man verstreut in OWASP, NIST oder den einschlägigen Audit-Reports – als in der Priorisierung. Ein Gründerteam, das zwischen Fundraising und Launch zwei Stunden für Security hat, bekommt hier eine ehrliche Antwort auf die Frage, welche zwei Stunden am meisten bringen. Dass das Ganze aus dem Crypto Valley kommt und den Schweizer sowie EU-Regulierungskontext direkt mitdenkt, macht es für hiesige Teams zusätzlich brauchbar.
Perdrizats Aufforderung im Vorwort ist entsprechend pragmatisch: Lesen, mit einer KI darüber diskutieren, umsetzen was zur eigenen Phase passt – und im nächsten Jahr wiederkommen und mehr umsetzen. Security ist ein laufender Prozess.
