Beispieldokument: Diese Regelung beschreibt den Sollprozess für die fiktive „Muster GmbH“. Produktive kryptografische Verfahren, Schlüssel, Zertifikate, Vertrauensanker, Laufzeiten, technische Baselines, Verantwortlichkeiten und Wirksamkeitsnachweise sind noch nicht vollständig erfasst oder bestätigt. Die Seite enthält keine geheimen Schlüsselwerte und belegt keine wirksam eingesetzte Verschlüsselung.
Technischer Hinweis: Konkrete Algorithmen, Protokolle, Schlüssellängen und zulässige Verwendungszeiträume werden in einer versionierten technischen Kryptografie-Baseline gepflegt. Sie werden regelmäßig gegen aktuelle BSI-Empfehlungen, Herstellerinformationen, Rechts-, Vertrags- und Kundenanforderungen geprüft.
TISAX-Hinweis: Die Kontrollfragen zur Kryptografie sind Bestandteil der 46 Informationssicherheitsfragen. Alle 46 Fragen werden umgesetzt und bewertet; eine individuelle Auswahl „anwendbar/nicht anwendbar“ wie in der Statement of Applicability ist nicht vorgesehen.
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-04-03 |
| Dokumentenart | Regelung / Kryptografie- und Schlüsselmanagement |
| Wiki.js-Pfad | /ISMS/04-Sicherheitsregelungen/Kryptografie-und-Schluessel |
| Verantwortlich | IT-Sicherheitsverantwortliche/r |
| Fachlich geprüft durch | IT-Leitung, ISMS-Beauftragte/r, Datenschutz, Recht/Compliance und relevante Systemverantwortliche |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – Kryptobestand und technische Baseline nicht bestätigt |
| Version | 0.1 |
| Stand | 23.07.2026 |
| Gültig ab | Nach Freigabe |
| Nächste Prüfung | Spätestens zwölf Monate nach Freigabe sowie bei technischer oder regulatorischer Änderung |
| Schutzklasse | Intern; Schlüssel-, Secret- und Konfigurationsdetails Streng vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 8.24 sowie Schnittstellen zu A 5.14, A 5.17, A 8.5 und A 8.12 |
| VDA-ISA-Bezug | ISA 6.0.3, Kapitel 5.1 Kryptografie |
| Technische Referenz | BSI TR-02102-1 und anwendungsbezogene Teile in der jeweils freigegebenen Fassung |
Diese Regelung legt fest, wie kryptografische Verfahren und kryptografisches Schlüsselmaterial ausgewählt, genehmigt, erzeugt, eingesetzt, gespeichert, verteilt, gesichert, erneuert, widerrufen, wiederhergestellt und sicher vernichtet werden.
Sie soll insbesondere sicherstellen, dass:
Die Regelung gilt für kryptografische Funktionen und Schlüsselmaterial in:
Passwörter, technische Identitäten und allgemeine Secrets werden ergänzend über Zugriff und Berechtigungen gesteuert.
| Anwendungszweck | Schutzziel |
|---|---|
| Verschlüsselung bei Übertragung | Vertraulichkeit und Integrität auf Kommunikationswegen |
| Verschlüsselung bei Speicherung | Schutz gespeicherter Informationen bei Verlust oder unbefugtem Zugriff |
| Integritätsprüfung | Erkennung unbefugter oder unbeabsichtigter Änderungen |
| Authentisierung | Verlässliche Prüfung von Identitäten, Diensten oder Geräten |
| Digitale Signatur | Authentizität, Integrität und gegebenenfalls Nachweisbarkeit |
| Schlüsselableitung | Sichere Erzeugung abgeleiteter Schlüssel aus zulässigem Ausgangsmaterial |
| Pseudonymisierung/Tokenisierung | Reduzierung unmittelbarer Personen- oder Datenbezüge |
| Code-/Artefaktsignierung | Schutz von Software- und Deploymentketten |
| Vertrauensbeziehungen | Absicherung von Zertifikaten, Geräten und Kommunikationspartnern |
Kryptografie schützt nur die vorgesehenen Schutzziele. Sie ersetzt keine Zugriffskontrolle, sichere Konfiguration, Protokollierung, Datensicherung oder physische Sicherheit.
| Rolle | Verantwortung |
|---|---|
| Geschäftsführung | Grundsätze, Ressourcen, wesentliche Ausnahmen und Restrisiken freigeben |
| IT-Sicherheitsverantwortliche/r | Kryptografiekonzept, Baseline, Register, Überwachung und technische Vorgaben koordinieren |
| IT-Leitung | Systeme, Dienste, Personal und Betriebsprozesse bereitstellen |
| Information Owner | Schutzbedarf, Verwendungszweck und geschäftliche Anforderungen festlegen |
| System-/Application Owner | Kryptografie im System planen, betreiben, dokumentieren und nachweisen |
| Schlüsselverantwortliche/r | Zugewiesenen Schlüsselbestand und Lebenszyklus fachlich verantworten |
| Schlüsselverwahrende Rolle | Geschütztes Schlüsselmaterial nach Verfahren verwahren oder bedienen |
| Administration | Genehmigte Konfigurationen umsetzen, ohne kritische Eigenfreigabe |
| Entwicklung | Freigegebene Bibliotheken, Verfahren und sichere Secret-Handhabung verwenden |
| ISMS-Beauftragte/r | Risiken, SoA, TISAX, Ausnahmen, Vorfälle und Audits koordinieren |
| Datenschutz | Schutz personenbezogener Daten, Pseudonymisierung und Nachweisminimierung beraten |
| Recht/Compliance | Signatur-, Export-, Vertrags-, Aufbewahrungs- und sonstige Rechtsanforderungen prüfen |
| Einkauf/Lieferantenmanagement | Kryptografie-, Schlüssel-, Cloud- und Exit-Anforderungen vertraglich steuern |
| Prüfer/in | Konfiguration, Register, Lebenszyklus und Wirksamkeit angemessen unabhängig prüfen |
Kritische Schlüssel werden nicht durch eine einzelne Person ohne angemessene Kontroll- und Vertretungsregel vollständig beherrscht.
Vor Einführung oder Änderung werden mindestens bewertet:
| Prüfaspekt | Leitfrage |
|---|---|
| Informationen | Welche Daten und Klassifizierungen sind betroffen? |
| Schutzziele | Welche Vertraulichkeits-, Integritäts-, Authentizitäts- oder Nachweisziele bestehen? |
| Bedrohung | Gegen welche Angreifer, Verlust- oder Manipulationsszenarien soll geschützt werden? |
| Lebensdauer | Wie lange muss das kryptografische Schutzniveau ausreichen? |
| Datenzustand | Übertragung, Speicherung, Verarbeitung, Sicherung oder Archivierung? |
| Systeme | Welche Plattformen, Geräte, Schnittstellen und Abhängigkeiten sind betroffen? |
| Nutzer/Rollen | Wer darf verschlüsseln, entschlüsseln, signieren, verwalten oder wiederherstellen? |
| Recht/Vertrag | Welche Kunden-, Datenschutz-, Signatur-, Export- oder Branchenanforderungen gelten? |
| Wiederherstellung | Welche Schlüssel müssen gesichert und im Notfall verfügbar sein? |
| Ablösung | Wie werden Verfahren und Schlüssel später migriert oder widerrufen? |
| Bedarfs-ID | Information/System | Schutzziel | Risiko/Anforderung | Kryptografische Maßnahme | Owner | Entscheidung | Status |
|---|---|---|---|---|---|---|---|
| Noch zu vergeben | Noch zu erfassen | Noch festzulegen | Noch zu bewerten | Noch festzulegen | Noch zu benennen | Ausstehend | Offen |
Die technische Baseline enthält mindestens:
| Baseline-Feld | Eintrag |
|---|---|
| Baseline-ID | Noch zu vergeben |
| Fachlicher Owner | Noch zu benennen |
| Technische Referenzen | BSI TR-02102 und weitere anwendungsbezogene Quellen |
| Geltungsbereich | Noch festzulegen |
| Version | Entwurf |
| Letzte Fachprüfung | Nicht durchgeführt |
| Freigabe | Ausstehend |
| Nächster Review | Noch festzulegen |
Konkrete Parameter werden nicht aus Gewohnheit übernommen. Sie werden gegen die aktuelle Referenz, Systemfähigkeit, Schutzdauer und Kundenanforderung geprüft.
Das Inventar erfasst mindestens:
| Feld | Mindestinhalt |
|---|---|
| Krypto-Objekt-ID | Eindeutige Referenz |
| System/Service | Betroffene Anwendung, Plattform oder Verbindung |
| Verwendungszweck | Verschlüsselung, Signatur, Authentisierung oder Integrität |
| Daten/Schutzbedarf | Geschützte Informationen und Klassifizierung |
| Verfahren/Protokoll | Referenz zur technischen Baseline |
| Schlüssel-/Zertifikatstyp | Symmetrisch, asymmetrisch, Zertifikat, Trust Anchor oder Secret |
| Owner | Verantwortliche Rolle |
| Betriebs-/Ablageort | KMS, HSM, Plattform, Gerät oder geschützte Ablage |
| Gültigkeit/Laufzeit | Aktivierung, Ablauf und Wechseltermin |
| Abhängigkeiten | Systeme, Gegenstellen, Backups und Recovery |
| Letzte Prüfung | Datum und Ergebnis |
| Status | Geplant, aktiv, abzulösen, widerrufen oder beendet |
| Krypto-Objekt-ID | System/Service | Zweck | Verfahrenreferenz | Owner | Ablauf/Review | Status |
|---|---|---|---|---|---|---|
| Noch zu vergeben | Noch zu erfassen | Noch festzulegen | Noch zuzuordnen | Noch zu benennen | Noch festzulegen | Nicht bewertet |
Geheime Schlüsselwerte, Passphrasen, Wiederherstellungscodes oder vollständige Secret-Standorte werden nicht im Wiki-Inventar gespeichert.
| Schlüsselart | Typischer Schutzbedarf | Besonderheit |
|---|---|---|
| Privater Signatur-/Identitätsschlüssel | Streng vertraulich | Nutzung muss eindeutig autorisiert und nachvollziehbar sein |
| Symmetrischer Daten-/Transport-Schlüssel | Streng vertraulich | Offenlegung kann Vertraulichkeit und Integrität brechen |
| Schlüsselverschlüsselungsschlüssel | Streng vertraulich | Schützt weitere Schlüssel und benötigt erhöhte Kontrolle |
| Root-/CA-Schlüssel | Streng vertraulich, sehr kritisch | Vertrauensanker mit weitreichenden Auswirkungen |
| Öffentlicher Schlüssel/Zertifikat | Integritätskritisch, grundsätzlich nicht geheim | Echtheit, Bindung und Gültigkeit müssen geschützt werden |
| Recovery-/Escrow-Schlüssel | Streng vertraulich | Zugriff nur für genehmigte Wiederherstellung |
| Testschlüssel | Nach Testscope | Darf nicht unkontrolliert in Produktion wiederverwendet werden |
| API-Secret/Token | Streng vertraulich nach Berechtigung | Zusätzlich nach Zugriff-und-Berechtigungen steuern |
Der Lebenszyklus umfasst:
Jede Lebenszyklusphase wird mit Verantwortung, Genehmigung und geeignetem Nachweis versehen.
Schlüssel werden:
erzeugt.
Für besonders kritische Schlüssel können HSM, Mehrpersonenfreigabe, dokumentierte Schlüsselzeremonie und Beweissicherung erforderlich sein.
Zufallszahlen für Schlüssel, Nonces, Tokens und andere Sicherheitsfunktionen stammen aus geeigneten kryptografischen Zufallszahlengeneratoren.
Geprüft werden:
Selbst konstruierte Zufallsverfahren oder vorhersagbare Werte werden nicht eingesetzt.
Schlüsselmaterial wird risikobasiert gespeichert in:
Mindestens gelten:
Schlüssel werden nur:
verteilt.
Bei manueller Übergabe werden Identität, Vollständigkeit, Integrität, Zeitpunkt, Empfänger und Rückmeldung dokumentiert. Verschlüsselter Inhalt und zugehöriges Geheimnis werden nicht unkontrolliert über denselben Kanal übertragen.
Vor Aktivierung werden:
Schlüssel werden nicht außerhalb des freigegebenen Zwecks oder für unvereinbare kryptografische Funktionen wiederverwendet.
Rotation erfolgt:
| Rotationsfeld | Mindestnachweis |
|---|---|
| Krypto-Objekt-ID | Eindeutige Zuordnung |
| Alter und neuer Schlüssel | Nur Metadaten/Referenzen, keine Werte |
| Anlass | Ablauf, Vorfall, Migration oder Regelturnus |
| Betroffene Systeme/Gegenstellen | Vollständiger Scope |
| Genehmigung | Verantwortliche Rolle |
| Wechseltermin | Geplant und tatsächlich |
| Test | Ver- und Entschlüsselung, Signatur oder Verbindung |
| Rückfall | Befristeter und geschützter Übergang |
| Altschlüssel | Widerruf, Archivierung oder Vernichtung |
Schlüssel und Zertifikate werden unverzüglich widerrufen oder gesperrt, wenn:
Widerrufsinformationen müssen für relevante prüfende Systeme rechtzeitig verfügbar und technisch berücksichtigt werden.
Schlüssel werden nur archiviert, wenn ein bestätigter Bedarf besteht, beispielsweise:
Archivierte Schlüssel erhalten:
Nicht mehr benötigte Schlüssel werden nicht vorsorglich unbegrenzt aufbewahrt.
Schlüsselmaterial wird so vernichtet, dass eine Wiederherstellung mit angemessenem Aufwand ausgeschlossen ist.
Berücksichtigt werden:
Die Vernichtung wird mit Objekt, Scope, Verfahren, verantwortlicher Rolle, Datum und Ergebnis dokumentiert.
Zertifikate werden über einen geregelten Lebenszyklus gesteuert:
| Zertifikatsfeld | Mindestinhalt |
|---|---|
| Zertifikats-ID | Eindeutige Referenz |
| Subject/Verwendungszweck | Technische oder organisatorische Bindung |
| Ausstellende CA | Vertrauensbeziehung |
| System/Service | Installations- und Nutzungsbereich |
| Owner | Verantwortliche Rolle |
| Ausstellung/Ablauf | Laufzeit |
| Schlüsselspeicher | Geschützte Referenz |
| Erneuerungsverantwortung | Benannte Rolle/Automation |
| Widerrufsweg | CRL, OCSP oder anderes Verfahren |
| Letzte Prüfung | Datum und Ergebnis |
Für interne oder externe Public-Key-Infrastrukturen werden geregelt:
Unbekannte, abgelaufene oder nicht freigegebene Vertrauensanker werden nicht unkontrolliert verteilt.
Für Übertragungen werden:
Die technische Baseline legt zulässige TLS-, VPN-, SSH-, E-Mail- und weitere Übertragungsverfahren fest. Aktuelle BSI-Empfehlungen werden regelmäßig eingearbeitet.
Verschlüsselung bei Speicherung wird risikobasiert eingesetzt für:
Bewertet werden auch:
Datenträgerverschlüsselung schützt nicht automatisch gegen einen berechtigten oder kompromittierten Zugriff im laufenden System.
Anwendungs- oder feldbezogene Verschlüsselung wird erwogen, wenn Plattform- oder Datenträgerverschlüsselung den Bedrohungen nicht genügt.
Mindestens zu klären sind:
Kryptografischer Schutz von Backups wird mit der Wiederanlaufplanung abgestimmt.
Es wird sichergestellt, dass:
Für Endgeräte und mobile Datenträger werden risikobasiert:
vorgesehen.
Die offene Maßnahme zu RIS-2026-011 wird im Risikoregister und Risikobehandlungsplan nachverfolgt. Eine vollständige Geräteverschlüsselung und Recoveryfähigkeit ist noch nicht nachgewiesen.
Passwörter werden nicht reversibel im Klartext gespeichert. Systeme verwenden freigegebene, für Passwortspeicherung geeignete Verfahren mit angemessenen Parametern und individuellen Zufallswerten.
Zusätzlich gelten:
Weitere Anforderungen regelt Zugriff und Berechtigungen.
Vor Einsatz digitaler Signaturen werden festgelegt:
Eine eingescannte Unterschrift oder ein Bild ist keine kryptografische digitale Signatur.
Signaturprozesse schützen Software, Skripte, Container, Pakete, Firmware und Deploymentartefakte.
Mindestens gelten:
Pseudonymisierung und Tokenisierung können Datenschutzrisiken reduzieren, sind aber nicht automatisch Anonymisierung.
Geprüft werden:
Die Bewertung wird mit Datenschutz im TISAX-Kontext abgestimmt.
Key-Management-Systeme und Hardware Security Modules werden risikobasiert eingesetzt.
Vor Auswahl und Betrieb werden bewertet:
Ein HSM oder KMS allein belegt nicht, dass Schlüssel korrekt erzeugt, zugeordnet, rotiert und genutzt werden.
Bei Cloud-Diensten wird entschieden, wer Schlüssel kontrolliert:
| Modell | Leitfrage |
|---|---|
| Provider-managed | Welche Kontrolle, Mandantentrennung, Rotation und Nachweise bietet der Anbieter? |
| Customer-managed | Wer administriert Schlüssel, Rechte, Rotation und Recovery? |
| Bring Your Own Key | Wie werden Import, Nutzung, Widerruf und Exit gesteuert? |
| Hold Your Own Key | Welche Architektur, Verfügbarkeit und Betriebsverantwortung bestehen? |
Vertrag, Regionen, Unterauftragnehmer, Behördenzugriff, Protokolle, Exit und Schlüsselvernichtung werden mit Lieferanten und Dienstleister geprüft.
Wenn externe Parteien Schlüssel, Zertifikate oder Kryptodienste verwalten, werden mindestens geregelt:
Systeme und Prozesse sollen den kontrollierten Wechsel von Verfahren, Parametern, Schlüsseln und Vertrauensankern ermöglichen.
Hierzu werden:
Bei Informationen mit langem Schutzbedarf und langfristig betriebenen Systemen wird bewertet:
Nicht standardisierte oder ungeprüfte „Post-Quantum“-Produkte werden nicht allein aufgrund von Marketingangaben eingesetzt.
Vor grenzüberschreitendem Einsatz, Lieferung oder Bereitstellung werden je nach Fall geprüft:
Die Prüfung erfolgt über das Rechts- und Vertragskataster und ersetzt keine rechtliche Einzelfallbewertung.
Überwacht werden risikobasiert:
Warnungen erhalten Owner, Priorität, Eskalationsweg und nachgewiesene Bearbeitung.
Verdacht besteht beispielsweise bei:
Die Meldung erfolgt über den Meldeweg für Sicherheitsvorfälle.
Risikobasiert werden:
Eine bloße Zertifikatserneuerung schließt die Untersuchung einer möglichen Kompromittierung nicht.
Für kritische Schlüsselbestände werden:
Nicht jeder Schlüssel darf wiederherstellbar sein. Der Bedarf wird je Verwendungszweck entschieden.
Kann die Baseline nicht eingehalten werden, wird vor Einsatz eine Ausnahme nach Ausnahmen und Risikoakzeptanzen beantragt.
Mindestens erforderlich sind:
Kompatibilität oder Herstellerstandard allein begründet keine unbefristete Ausnahme.
| ISA-Kapitel | Themengebiet | Kontrollfragen ISA 6.0.3 | Inhalt dieser Regelung | Status |
|---|---|---|---|---|
| 5.1 | Kryptografie | 2 | Kryptografiekonzept, technische Baseline, Schlüssel- und Zertifikatsmanagement | 0 von 2 bewertet |
Für jede Kontrollfrage werden in der VDA-ISA-Selbsteinschätzung tatsächliche Umsetzung, Referenzen, Nachweise, Reifegrad, Lücken und Maßnahmen dokumentiert.
Die beiden Kontrollfragen sind Bestandteil der 46 Informationssicherheitsfragen und werden nicht individuell ausgeschlossen.
| Annex-A-Control | Behandlung in dieser Regelung | Aktueller Status |
|---|---|---|
| A.8.24 Einsatz von Kryptografie | Auswahl, Einsatz, Baseline und vollständiger Schlüssel-Lebenszyklus | Geplant; Kryptobestand und Umsetzung nicht geprüft |
| A.5.14 Informationsübertragung | Kryptografischer Schutz und Gegenstellenauthentisierung | Geplant; Verbindungen nicht inventarisiert |
| A.5.17 Authentisierungsinformationen | Schutz kryptografischer Authentisierungsmittel | Geplant; technische Nachweise offen |
| A.8.5 Sichere Authentisierung | Zertifikate, Tokens und kryptografische Verfahren | Geplant; Konfiguration nicht geprüft |
| A.8.12 Verhinderung von Datenabfluss | Verschlüsselung als mögliche risikobasierte Schutzmaßnahme | Geplant; Wirksamkeit nicht geprüft |
Die Anwendbarkeit und Umsetzung der ISO-Maßnahmen wird in der Statement of Applicability freigegeben. Diese Regelung ersetzt keine SoA-Entscheidung.
| Steuerungsobjekt | Nachweisbarer Stand |
|---|---|
| Technische Kryptografie-Baseline | Nicht erstellt beziehungsweise nicht freigegeben |
| Kryptografisches Inventar | Nicht vollständig erfasst |
| Schlüssel- und Zertifikatsregister | Nicht vorgelegt |
| Verantwortliche Owner | Nicht vollständig benannt |
| KMS-/HSM-Bestand | Nicht bestätigt |
| Schlüsselgenerierung und -verteilung | Nicht geprüft |
| Rotation und Widerruf | Nicht systematisch nachgewiesen |
| Zertifikatsüberwachung | Nicht bestätigt |
| Backup-/Recovery-Schlüssel | Nicht inventarisiert oder getestet |
| Cloud-Schlüsselmodelle | Nicht bewertet |
| Schwache oder veraltete Verfahren | Nicht vollständig identifiziert |
| Kryptografische Agilität | Nicht bewertet |
| TISAX-Kapitel 5.1 | 0 von 2 Kontrollfragen bewertet |
| Wirksamkeitsnachweise | Nicht vorgelegt |
Bewertung: Die Regelungsstruktur ist vorhanden. Eine Aussage zur tatsächlichen Verschlüsselungsabdeckung, Schlüsselkontrolle, ISO-Konformität oder TISAX-Reife ist nicht zulässig.
Mindestens erforderlich sind:
Nachweise werden referenziert und geschützt abgelegt. Geheime Schlüsselwerte werden keinem Auditbericht oder Wiki-Eintrag beigefügt.
| Kontrolle | Prüfgegenstand | Entwurfsturnus | Nachweisstatus |
|---|---|---|---|
| Krypto-Inventarreview | Systeme, Verfahren, Owner und Status | Vierteljährlich im Entwurf | Nicht durchgeführt |
| Zertifikatsablauf | Vollständigkeit, Warnung und Erneuerung | Kontinuierlich/regelmäßig | Nicht nachgewiesen |
| Baseline-Abgleich | Verfahren und Parameter gegen aktuelle Referenzen | Mindestens jährlich/anlassbezogen | Nicht durchgeführt |
| Schlüsselrotation | Fällige und tatsächlich gewechselte Schlüssel | Regelmäßig | Nicht nachgewiesen |
| Widerrufstest | Sperrung und technische Berücksichtigung | Noch festzulegen | Nicht getestet |
| KMS-/HSM-Rechte | Owner, Administratoren und Funktionstrennung | Vierteljährlich im Entwurf | Nicht durchgeführt |
| Recoverytest | Wiederherstellung benötigter Schlüssel | Nach BCM-Testplan | Nicht getestet |
| Übertragungsprüfung | Protokolle, Zertifikate und Fallbacks | Risikobasiert | Nicht durchgeführt |
| Speicherverschlüsselung | Geräte, Server, Backups und Schlüsseltrennung | Risikobasiert | Nicht durchgeführt |
| Kompromittierungsübung | Erkennung, Widerruf, Wechsel und Kommunikation | Noch festzulegen | Nicht durchgeführt |
Entwurfsturnusse sind vor Freigabe risikobasiert zu bestätigen.
| Kennzahl | Berechnung | Entwurfsziel | Aktueller Stand |
|---|---|---|---|
| Inventarabdeckung | Erfasste / identifizierte Krypto-Objekte | 100 % | Nicht messbar |
| Owner-Abdeckung | Objekte mit Owner / erfasste Objekte | 100 % | Nicht messbar |
| Fristgerecht erneuerte Zertifikate | Rechtzeitig erneuerte / fällige Zertifikate | 100 % | Nicht erhoben |
| Fristgerecht rotierte Schlüssel | Rechtzeitig rotierte / fällige Schlüssel | 100 % | Nicht erhoben |
| Baselinekonforme Objekte | Konforme / geprüfte Krypto-Objekte | 100 % oder freigegebene Ausnahme | Nicht erhoben |
| Offene kritische Ausnahmen | Nicht kompensierte kritische Abweichungen | 0 | Nicht erhoben |
| Erfolgreiche Recoverytests | Erfolgreiche / geplante Tests | 100 % | 0 Tests nachgewiesen |
| Rechtzeitig behandelte Warnungen | Fristgerecht geschlossene / fällige Warnungen | 100 % | Nicht erhoben |
| TISAX-Kontrollfragen 5.1 | Bewertete / 2 | 2 von 2 | 0 von 2 |
Kennzahlen dürfen kompromittierte Schlüssel, unerkannte Altverfahren oder fehlende Grundgesamtheiten nicht verdecken.
Eine Kryptografiemaßnahme gilt nicht allein durch aktivierte Einstellungen, ein Zertifikat oder eine Produktbeschreibung als wirksam.
Geeignete Wirksamkeitsnachweise sind beispielsweise:
Feststellungen werden über Abweichungen und Korrekturmaßnahmen behandelt.
Kryptografie und Schlüsselmanagement werden über das Auditprogramm und Interne Audits risikobasiert geprüft.
Mögliche Stichproben:
Ein positives Ergebnis gilt nur für Scope und Stichprobe.
| Offener Punkt | Verantwortung | Status |
|---|---|---|
| Technische Kryptografie-Baseline erstellen und freigeben | IT-Sicherheit / IT-Leitung | Offen |
| Vollständiges Kryptografie-Inventar erstellen | System-/Application Owner | Offen |
| Schlüssel-, Zertifikats- und Trust-Anchor-Register aufbauen | IT-Sicherheit / IT-Betrieb | Offen |
| Owner und Funktionstrennung festlegen | IT-Leitung / Fachbereiche | Offen |
| KMS-/HSM- und Secret-Store-Bestand bewerten | IT-Sicherheit | Offen |
| Schwache und veraltete Verfahren identifizieren | IT-Sicherheit / System-Owner | Offen |
| Zertifikats- und Ablaufüberwachung einrichten | IT-Betrieb | Offen |
| Rotations- und Widerrufsverfahren testen | IT-Betrieb / ISMS | Offen |
| Backup- und Recovery-Schlüssel testen | IT / BCM | Offen |
| Cloud-Schlüsselkontrolle und Exit bewerten | IT / Einkauf / Datenschutz | Offen |
| Kryptografie-Agilität und Langzeitschutz bewerten | IT-Sicherheit / Architektur | Offen |
| TISAX-Kapitel 5.1 kontrollfragenbezogen bewerten | TISAX / IT-Sicherheit | Offen |
| Prüffrage | Status Entwurf |
|---|---|
| Ist eine aktuelle technische Kryptografie-Baseline freigegeben? | Nein |
| Sind alle kryptografischen Verfahren und Objekte inventarisiert? | Nein |
| Sind Owner, Zwecke und Schutzbedarfe dokumentiert? | Nein |
| Sind Schlüsselgenerierung und Zufallsquellen geprüft? | Nein |
| Sind Schlüssel geschützt gespeichert und verteilt? | Nicht nachgewiesen |
| Funktionieren Rotation, Widerruf und Vernichtung? | Nicht geprüft |
| Werden Zertifikate und Laufzeiten überwacht? | Nicht nachgewiesen |
| Sind KMS-/HSM-Rechte und Funktionstrennung geprüft? | Nein |
| Sind Cloud- und Lieferantenschlüssel bewertet? | Nein |
| Sind Backup- und Recovery-Schlüssel getestet? | Nein |
| Sind veraltete Verfahren und Migrationen gesteuert? | Nein |
| Sind beide Kontrollfragen aus Kapitel 5.1 bewertet? | Nein; 0 von 2 |
| Sind die zugehörigen 46 Informationssicherheitsfragen vollständig berücksichtigt? | Ja als Sollumfang; 0 von 46 bewertet |
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 23.07.2026 | Regelung für Kryptografieverfahren, Schlüssel-, Zertifikats-, KMS-/HSM- und Kompromittierungsmanagement angelegt | IT-Sicherheit / ISMS | Ausstehend | – |
| Funktion | Name | Entscheidung | Datum |
|---|---|---|---|
| Geschäftsführung | – | Ausstehend | – |
| IT-Sicherheitsverantwortliche/r | – | Fachliche Prüfung ausstehend | – |
| IT-Leitung | – | Betriebsprüfung ausstehend | – |
| ISMS/Datenschutz/Recht | – | Schnittstellenprüfung ausstehend | – |
Maßgeblich bleiben die aktuelle freigegebene technische Baseline, die lizenzierten Normtexte, die offizielle ISA-Arbeitsmappe, der bestätigte Assessment Scope sowie die Rechts-, Vertrags-, Kunden- und Unternehmensanforderungen.