Ist Ihr PoC entscheidungsreif?

swiyu Readiness Check – 42 Prüffragen, 15 Minuten, eine belastbare Antwort

Ein technischer Prototyp beweist, dass es geht. Er beweist nicht, dass Sie produktiv gehen können. Der Readiness Check geht mit Ihnen die 42 Fragen durch, an denen sich das entscheidet – von Use Case und Datenquelle über DID und Schlüsselkontrolle bis zu Widerruf, Security und Betrieb.

Check starten

Was der Check prüft

Use Case und Credential

Welches fachliche Problem der Nachweis löst, was er beweisen muss, wer ihn ausstellt, hält und prüft – und wann er widerrufen wird.

Daten und Datenschutz

Führende Datenquelle, minimierter Datenumfang, Rechtsgrundlage und die Frage, welche Personendaten nie in Logs erscheinen dürfen.

Organisation und Registry

Issuer- oder Verifier-Rolle, zu registrierende juristische Einheit, fachliche und technische Verantwortung, interne Freigabewege.

DID und Schlüsselmanagement

Wer die DID kontrolliert, wo private Schlüssel liegen, wie Rotation und Wiederherstellung funktionieren – und was bei Kompromittierung gilt.

Integration und Widerruf

Auslöser für Ausstellung und Widerruf, Einbettung in Ihre Fachanwendungen, Fehlerfälle und ein realistischer End-to-End-Test.

Security und Betrieb

Bedrohungsmodell, Monitoring und Alarmierung, Support und Eskalation, Runbooks und ein getesteter Incident-Prozess.

Interaktive Checkliste

swiyu Readiness Check

Bewerten Sie jede Frage ehrlich. Das Ergebnis ist nur so belastbar wie Ihre Antworten.

42 Prüffragen für einen belastbaren PoC

Sie durchlaufen sechs Abschnitte mit je sieben Fragen. Am Ende sehen Sie sofort, ob Ihr Vorhaben grün, gelb oder rot steht – und erhalten auf Wunsch eine PDF-Auswertung mit Empfehlungen je Abschnitt und einem vorbereiteten Entscheidungslog.

  • ~15 Min.
  • 42 Fragen
  • 6 Abschnitte

Bewerten Sie jede Frage gemeinsam mit Fachbereich, Architektur, Security und Betrieb. Markieren Sie genau einen Status und dokumentieren Sie offene Entscheidungen, Verantwortliche und Termine.

1. Use Case und Credential

Ziel: Entscheidungen sichtbar machen. Nicht nur technische Funktion demonstrieren.

Geklärt Entscheidung dokumentiert Teilweise Richtung klar, Details offen Offen Entscheidung fehlt N/A Für den Use Case nicht relevant

1Welches konkrete fachliche Problem soll mit dem Nachweis gelöst werden?

2Welche Aussage muss der Nachweis für den Geschäftsfall beweisen?

3Wer stellt den Nachweis aus, wer hält ihn und wer prüft ihn?

4Welcher messbare Nutzen oder welches Risiko soll durch den Prozess verbessert werden?

5Welche Gültigkeitsdauer und welche zeitlichen Einschränkungen gelten?

6Unter welchen fachlichen Bedingungen muss der Nachweis widerrufen werden?

7Ist der passende Credential-Typ und das vorgesehene Format dokumentiert?

2. Daten und Datenschutz

Ziel: Entscheidungen sichtbar machen. Nicht nur technische Funktion demonstrieren.

Geklärt Entscheidung dokumentiert Teilweise Richtung klar, Details offen Offen Entscheidung fehlt N/A Für den Use Case nicht relevant

1Welche Angaben sind für die Prüfung zwingend erforderlich?

2Welche Angaben dürfen bewusst nicht in den Nachweis aufgenommen werden?

3Welches System ist die führende und verlässliche Datenquelle?

4Sind Zweck, Rechtsgrundlage und interne Freigabe für die Datenverarbeitung geklärt?

5Kann der Verifier nur die für den Zweck notwendigen Angaben anfordern?

6Welche Ereignisse werden protokolliert und welche Personendaten dürfen nicht in Logs erscheinen?

7Sind Aufbewahrung, Löschung und die ausschliessliche Nutzung geeigneter Testdaten geregelt?

3. Organisation und Registry

Ziel: Entscheidungen sichtbar machen. Nicht nur technische Funktion demonstrieren.

Geklärt Entscheidung dokumentiert Teilweise Richtung klar, Details offen Offen Entscheidung fehlt N/A Für den Use Case nicht relevant

1Ist geklärt, ob die Organisation als Issuer, Verifier oder in beiden Rollen auftritt?

2Welche juristische Einheit wird registriert und wer darf sie vertreten?

3Wer trägt die fachliche Gesamtverantwortung für den Use Case?

4Wer verantwortet technische Einrichtung, Betrieb und Änderungen?

5Welche Einträge und Nachweise werden für Basis- und Vertrauensregister benötigt?

6Wie werden Credential-Schema, Ausstellung und Prüfregeln intern freigegeben?

7Welche externen Betreiber, Lieferanten oder weiteren Abhängigkeiten sind beteiligt?

4. DID und Schlüsselmanagement

Ziel: Entscheidungen sichtbar machen. Nicht nur technische Funktion demonstrieren.

Geklärt Entscheidung dokumentiert Teilweise Richtung klar, Details offen Offen Entscheidung fehlt N/A Für den Use Case nicht relevant

1Welche DID wird verwendet und wer kontrolliert sie organisatorisch?

2Wie und in welcher Umgebung wird das Schlüsselmaterial erzeugt?

3Wo werden private Schlüssel gespeichert und technisch geschützt?

4Welche Rollen dürfen Schlüssel verwenden und wie ist die Funktionstrennung umgesetzt?

5Wie erfolgen Rotation, Ablauf und kontrollierter Austausch von Schlüsseln?

6Wie funktionieren Wiederherstellung, Notfallzugriff und dokumentierte Übergaben?

7Welche Schritte gelten bei Verdacht auf Kompromittierung oder Verlust eines Schlüssels?

5. Integration und Widerruf

Ziel: Entscheidungen sichtbar machen. Nicht nur technische Funktion demonstrieren.

Geklärt Entscheidung dokumentiert Teilweise Richtung klar, Details offen Offen Entscheidung fehlt N/A Für den Use Case nicht relevant

1Welche Fachsysteme liefern Daten oder empfangen Prüfergebnisse?

2Was löst die Ausstellung eines Nachweises technisch aus?

3Welche fachliche oder technische Freigabe ist vor der Ausstellung erforderlich?

4Wie wird die Prüfung in Web-, Mobile- oder Fachanwendungen eingebettet?

5Wie werden Fehler, Wiederholungen, Zeitüberschreitungen und Abbrüche behandelt?

6Was löst einen Widerruf aus und wie schnell wird er für Verifier wirksam?

7Ist ein End-to-End-Test mit realistischen Systemgrenzen und Testfällen definiert?

6. Security und Betrieb

Ziel: Entscheidungen sichtbar machen. Nicht nur technische Funktion demonstrieren.

Geklärt Entscheidung dokumentiert Teilweise Richtung klar, Details offen Offen Entscheidung fehlt N/A Für den Use Case nicht relevant

1Sind Bedrohungsmodell und wichtigste Missbrauchsszenarien dokumentiert?

2Welche Ereignisse, Fehler und Sicherheitsindikatoren werden überwacht und alarmiert?

3Sind Logging, Datenschutz und Zugriff auf Betriebsdaten abgestimmt?

4Wie werden Releases, Konfigurationsänderungen und Abhängigkeiten kontrolliert?

5Wer übernimmt Support, Eskalation und Kommunikation bei Störungen?

6Gibt es Runbooks, Verantwortlichkeiten und einen getesteten Incident-Prozess?

7Welche offenen Punkte blockieren einen produktiven Betrieb und wie sieht die Roadmap aus?

Auswertung als PDF erhalten

Wir senden Ihnen eine PDF-Auswertung mit Empfehlungen zu jedem Abschnitt, den fünf kritischen Kontrollpunkten und einem vorbereiteten Entscheidungslog Ihrer offenen Punkte.

Eigenständiges Angebot von b-nova. Keine offizielle Partnerschaft mit Bund oder swiyu.

Warum diese 42 Fragen

Aus echten Projekten

Die Fragen stammen aus der Arbeit an e-ID- und Credential-Projekten – nicht aus einer Standard-Vorlage.

Entscheidung statt Demo

Der Check trennt die technische Demo vom belastbaren PoC. Genau an dieser Stelle scheitern die meisten Vorhaben.

Fünf kritische Kontrollpunkte

Eigentümer, Datenquelle, Schlüsselkontrolle, Widerruf und Betrieb. Ist einer davon offen, ist das Vorhaben nicht entscheidungsreif – unabhängig vom Rest.

Ehrliches Ergebnis

Kein Score, der Ihnen schmeichelt. Ein offener Kontrollpunkt führt zu Rot, auch wenn alles andere grün ist.

Direkt weiterarbeiten

Das Entscheidungslog im PDF listet Ihre offenen Punkte bereits auf. Sie ergänzen Verantwortliche und Termine.

Keine Verpflichtung

Die Auswertung ist kostenlos. Ob daraus ein Gespräch wird, entscheiden Sie.

Offene Punkte gefunden?

Das swiyu Readiness Kit schliesst genau diese Lücken – von der Use-Case-Auswahl über DID und Generic Issuer/Verifier bis zum produktiven Betrieb.