DEEN

Selbsttest

Nachweisfähigkeits-Check: Was kann Ihr System im Ernstfall belegen?

Zehn Fragen aus echten Audits, Security-Fragebögen und Vorfallanalysen. Sie brauchen keine Unterlagen, nur eine ehrliche Einschätzung. Die Auswertung erscheint sofort auf dieser Seite.

Die Fragen sind bewusst binär gestellt. Ein „vermutlich schon“ zählt in einer Prüfung als Nein, weil der Beleg fehlt — deshalb gibt es hier dieselbe Härte.

Zu jeder Frage können Sie aufklappen, welche Anforderung dahintersteht und was in der Praxis meist stattdessen vorliegt.

Nichts wird gespeichert oder übertragen. Die Auswertung entsteht in Ihrem Browser und ist weg, sobald Sie die Seite schließen.

0 von 10 Fragen beantwortet

  1. 01Können Sie für einen beliebigen Datensatz lückenlos zeigen, wer ihn wann und warum geändert hat?

    Nicht der aktuelle Stand, sondern die vollständige Kette der Änderungen samt Auslöser.

    Warum diese Frage

    Die Rechenschaftspflicht aus DSGVO Art. 5 Abs. 2 verlangt, dass Sie belegen können, was mit personenbezogenen Daten passiert ist — nicht nur, dass Sie es geregelt haben. Bei Betroffenenanfragen oder Rückfragen der Aufsichtsbehörde reicht der aktuelle Stand nicht. Die meisten Systeme können genau das nicht: Sie zeigen den Ist-Zustand und irgendwelche Events, aber nicht die geschlossene Kette samt Auslöser.

  2. 02Ist diese Historie technisch unveränderlich — also auch für Administratoren und die Anwendung selbst?

    Ein Protokoll in derselben Datenbank mit Schreibrechten der Anwendung zählt hier als Nein.

    Warum diese Frage

    „Wir haben Logging“ ist nicht dasselbe wie „das Log ist nicht manipulierbar“. Liegt das Audit-Log in derselben Datenbank wie die Geschäftsdaten und darf die Anwendung darauf schreiben, ist es als Beweismittel schwach. Wenn Sie Finanzkunden beliefern, wird das über DORA und die zugehörigen technischen Regulierungsstandards explizit adressiert: Logs müssen gegen Manipulation geschützt sein.

  3. 03Können Sie den Zustand eines Vorgangs zu einem beliebigen Stichtag rekonstruieren?

    Typische Prüferfrage: „Wie sah dieser Fall am 14. März aus?“

    Warum diese Frage

    Das ist die Frage, an der die meisten Standardantworten brechen. Ein SIEM zeigt Ihnen Events — es rekonstruiert nicht automatisch den vollständigen Zustand eines Geschäftsobjekts an einem bestimmten Tag. NIS2 verlangt in der Umsetzung die Fähigkeit, Vorfälle nachzuvollziehen, und ohne Stichtagszustand ist jede Nachvollziehung Handarbeit.

  4. 04Ist die Mandantentrennung technisch durchgesetzt statt über Filterbedingungen im Anwendungscode?

    Wenn ein vergessener Filter Daten anderer Mandanten sichtbar machen könnte, ist die Antwort Nein.

    Warum diese Frage

    Ein vergessenes `WHERE tenant_id = …` ist der klassische Cross-Tenant-Leak. Prüfer und Enterprise-Kunden fragen zunehmend nach technischer Isolation — Row-Level-Security auf Datenbankebene, getrennte Schemas oder Policy-Durchsetzung außerhalb der Anwendung — statt nach Code-Disziplin. Über die Lieferkettenanforderungen von NIS2 wird das auch zum Thema Ihrer Kunden, nicht nur zu Ihrem.

  5. 05Können Sie belegen, wer vor sechs Monaten welche Berechtigung hatte und wer sie erteilt hat?

    Nicht das heutige Rechtemodell — der Stand von damals.

    Warum diese Frage

    Zugriffskontrolle nach DSGVO Art. 32 wird in Prüfungen selten als Konzept abgefragt, sondern als Historie: Wer durfte damals was, und wer hat es vergeben? Die meisten Systeme kennen nur den aktuellen Rechtestand. Bei internen Untersuchungen und Haftungsfragen ist genau diese Lücke teuer.

  6. 06Liegen Identität und Zugriffssteuerung so bei Ihnen, dass Sie sie ohne Anbieterwechselprojekt anpassen können?

    Souveränität über Identität: eigene Realms, eigene Audit-Events, keine Blackbox.

    Warum diese Frage

    Wenn Sie eine Anforderung Ihres Kunden nur mit einem Migrationsprojekt erfüllen können, ist der Anbieter Teil Ihres Risikos. Für regulierte Kunden — besonders im Finanzumfeld unter DORA — wird Black-Box-IAM zunehmend zum Ausschlusskriterium in der Lieferantenprüfung.

  7. 07Könnten Sie nach einem Vorfall innerhalb von 24 Stunden sagen, welche Mandanten und Datensätze betroffen sind?

    Die Meldefrist läuft ab Kenntnis, nicht ab Analyseende.

    Warum diese Frage

    Das ist die schärfste operative Anforderung im ganzen Check. NIS2 verlangt eine Frühwarnung binnen 24 Stunden ab Kenntnis, die vollständige Meldung binnen 72 Stunden; die DSGVO-Frist nach Art. 33 beträgt 72 Stunden ab Kenntnis. Ein dokumentierter Incident-Response-Prozess hilft dabei nur, wenn die technischen Voraussetzungen für schnelle Scope-Klärung da sind — sonst ist er ein Feuerwehrplan ohne Hydranten.

  8. 08Ist zu jeder Produktionsänderung nachvollziehbar, was sie ausgelöst hat und wer sie freigegeben hat?

    Bei maschinell erzeugtem Code besonders relevant: Herkunft statt Autorenname.

    Warum diese Frage

    Nachvollziehbares Change-Management ist in NIS2 und DORA verankert. Neu ist die Verschiebung der Frage: Bei KI-gestützt erzeugtem Code sagt der Autorenname im Commit wenig aus. Belegbar wird es über Herkunft — welcher Auslöser, welcher Kontext, welche Freigabe.

  9. 09Werden automatisierte oder KI-gestützte Entscheidungen samt Datenstand und Modellversion festgehalten?

    Nur relevant, wenn Sie automatisiert entscheiden — sonst mit „Unklar“ überspringen.

    Warum diese Frage

    Für Hochrisiko-Systeme verlangt Art. 12 des AI Act die automatische Aufzeichnung relevanter Ereignisse über den Lebenszyklus. Unabhängig davon greift DSGVO Art. 22 bei Entscheidungen mit rechtlicher Wirkung. Wer KI-Funktionen nachrüstet, hat den Datenstand zum Entscheidungszeitpunkt und die Modellversion meist nicht mitprotokolliert — und kann die Entscheidung damit später nicht erklären.

  10. 10Kann der Fachbereich diese Fragen ohne Entwicklerhilfe beantworten?

    Wenn jede Anfrage ein Ticket auslöst, ist die Nachweisfähigkeit organisatorisch, nicht technisch.

    Warum diese Frage

    Der organisatorische Lackmustest. Wenn Logs nur dem Security- oder Ops-Team zugänglich sind und jede Nachweisanfrage ein Engineering-Ticket auslöst, ist die Nachweisfähigkeit im Ernstfall nicht abrufbar — egal wie gut die Technik theoretisch ist. Enterprise-Kunden und Prüfer merken das innerhalb weniger Rückfragen.

Ihre Auswertung

Keine offenen Punkte — beantworten Sie die Fragen, um die Auswertung zu sehen.

Der Check ersetzt keine Prüfung und keine Rechtsberatung. Er bildet die Fragen ab, die uns in Projekten und Audits regelmäßig begegnen. Welche Regulierung für Sie konkret gilt, hängt von Branche, Größe und Rolle in der Lieferkette ab.

Antworten, die im Fragebogen gut aussehen

Vier Formulierungen tauchen in fast jedem Security-Fragebogen auf. Sie sind nicht falsch, und sie sind auch nicht als Täuschung gemeint. Sie signalisieren schnell, dass das Thema bearbeitet wurde, und heben das Gespräch auf eine prozessuale Ebene, auf der man nicht sofort in technische Details muss.

Gegen oberflächliche Fragen funktioniert das. Sie brechen erst bei der gezielten Nachfrage: „Zeigen Sie mir den Stand vom 14. März für diesen Datensatz — und wer damals welche Rechte hatte.“ Genau danach fragt dieser Check.

  • „Wir sind ISO-27001-zertifiziert.“

    ISO/IEC 27001 ist der Standard für ein Informationssicherheits-Managementsystem. Er verlangt, dass Risiken systematisch bewertet, Maßnahmen definiert und dokumentiert und regelmäßig auditiert werden.

    Deckt ab
    Dokumentierte Richtlinien zu Logging, Zugriffskontrolle und Incident Handling. Risikobewertungen, Maßnahmenkataloge, interne und externe Audits des Managementsystems.
    Liefert nicht
    Eine Aussage darüber, wie gut die technischen Nachweise in einem konkreten System sind. Ein zertifiziertes Unternehmen kann veränderliche Application-Logs haben, keine Stichtags-Rekonstruktion können und bei einem Vorfall tagelang brauchen, um den Scope zu klären. Geprüft wird das Managementsystem, nicht die Fähigkeit, den Zustand vom 14. März unveränderlich zu belegen.

    Offen bleiben: Fragen 1, 2, 3, 7

  • „Wir haben Audit-Logs und ein SIEM.“

    Audit-Logs protokollieren, wer wann was getan hat. Ein SIEM sammelt Logs aus vielen Quellen, korreliert sie und erzeugt Alarme — es hilft bei Erkennung und Untersuchung von Vorfällen.

    Deckt ab
    Ereignisse werden aufgezeichnet. Es gibt eine zentrale, durchsuchbare Stelle. In vielen Fällen lässt sich nachvollziehen, dass etwas passiert ist.
    Liefert nicht
    Unveränderlichkeit — die meisten Application-Audit-Logs liegen in derselben Datenbank wie die Geschäftsdaten und sind für Admins und die Anwendung schreibbar. Vollständigkeit der Kette samt Auslöser. Den Stichtagszustand eines Geschäftsobjekts, denn ein SIEM zeigt Events, nicht Zustände. Den Rechtestand von vor sechs Monaten. Und Zugänglichkeit für den Fachbereich.

    Offen bleiben: Fragen 1, 2, 3, 5, 10

  • „Tenant-Isolation ist implementiert.“

    Mandantentrennung bedeutet, dass Daten und Aktionen eines Kunden strikt von denen anderer getrennt sind — im Multi-Tenant-SaaS die zentrale Sicherheitszusage.

    Deckt ab
    Es gibt eine Form der Trennung und die klare Absicht, dass Mandanten nicht ineinandergreifen.
    Liefert nicht
    Die entscheidende Unterscheidung: technisch durchgesetzt oder nur über Filterbedingungen im Anwendungscode. Läuft die Trennung über `WHERE tenant_id = …`, genügt ein vergessener Filter oder ein Bug. Echte Isolation — getrennte Datenbanken, Row-Level-Security auf DB-Ebene, Policy-Durchsetzung außerhalb der Anwendung — ist seltener und teurer. Das Wort „implementiert“ verschweigt genau das Wie.

    Offen bleiben: Frage 4

  • „Bei Vorfällen haben wir einen Incident-Response-Prozess.“

    Ein dokumentierter Ablauf für Sicherheits- und Betriebsvorfälle: Erkennung, Eindämmung, Analyse, Behebung, Nachbereitung — meist orientiert an NIST oder ISO/IEC 27035.

    Deckt ab
    Rollen, Eskalationswege, Playbooks, Kommunikationspläne. Damit ist die prozessuale Seite der Anforderungen aus NIS2 und DORA abgedeckt: Verfahren müssen vorhanden sein.
    Liefert nicht
    Die Fähigkeit, den Scope schnell und belegbar zu klären. Der Prozess sagt, dass analysiert wird. Er garantiert nicht, dass Sie binnen 24 Stunden benennen können, welche Mandanten und Datensätze betroffen sind. Fehlen unveränderliche Historie, schnelle Abfragbarkeit und Rechtehistorie, dauert die Analyse Tage — die Meldefrist läuft trotzdem.

    Offen bleiben: Fragen 1, 5, 7

Der Gedanke hinter diesen Antworten ist nachvollziehbar: Man hat die organisatorischen Bausteine, die in Checklisten stehen. Der Check fragt stattdessen nach der technischen und organisatorischen Belegbarkeit im Ernstfall. Wer darauf früh „Ja, belegbar“ sagen und es zeigen kann, hat gegenüber Kunden in regulierten Branchen einen Vorteil, der sich nicht wegargumentieren lässt.

Häufige Fragen zum Check

Werden meine Antworten gespeichert?
Nein. Die Auswertung läuft vollständig in Ihrem Browser. Es werden keine Antworten übertragen, gespeichert oder ausgewertet.
Wie belastbar ist das Ergebnis?
Es ist eine Selbsteinschätzung, keine Prüfung. Der Wert liegt darin, die richtigen Fragen einmal bewusst durchzugehen — die meisten Lücken sind danach benannt, nicht mehr diffus.
Was, wenn ich bei mehreren Fragen „Unklar“ ankreuze?
Das ist selbst ein Befund. „Unklar“ heißt in einer Prüfung, dass der Nachweis im Moment der Frage nicht vorliegt — deshalb zählen wir es zu den offenen Punkten.
Reicht eine ISO-27001-Zertifizierung nicht aus?
Sie belegt ein funktionierendes Informationssicherheits-Managementsystem — also Richtlinien, Risikobewertung und Auditzyklus. Sie sagt nichts darüber, ob Ihr System den Zustand eines Datensatzes an einem bestimmten Tag unveränderlich rekonstruieren kann. Beides ist nützlich, aber es beantwortet unterschiedliche Fragen.
Gilt das auch für uns, wenn wir nicht direkt reguliert sind?
Meistens ja, nur indirekt. Sobald ein Kunde unter NIS2, DORA oder den AI Act fällt, gibt er die Anforderungen über Security-Fragebögen, Auftragsverarbeitungsverträge und Lieferantenprüfungen an Sie weiter. Der Auslöser ist dann kein Prüfer, sondern ein Deal.

Auswertung besprechen?

Schildern Sie Ihre Situation in ein paar Sätzen. Sie bekommen eine Einschätzung, ob und wo sich ein Schnitt lohnt — und wann er sich nicht lohnt.

Situation schildernNIS2 in der Umsetzung