VAIT im Fokus: IT-Aufsicht für Versicherer erklärt
W
er die IT-Aufsicht im Versicherungssektor verstehen will, kommt an einem Kürzel nicht vorbei: VAIT – die versicherungsaufsichtlichen Anforderungen an die IT. Hinter dem Begriff verbirgt sich kein reines Technikpapier, sondern eine klare Erwartungshaltung der Aufsicht an Governance, Organisation und Betrieb der IT bei Versicherungsunternehmen. VAIT macht deutlich: IT ist nicht Hilfsdisziplin, sondern Kern der Wertschöpfung – vom Antrag bis zur Leistung, vom Aktuariat bis zur Kapitalanlage, vom Vermittlerportal bis zum Schadenworkflow. Dieser Beitrag ordnet VAIT ein, erklärt die gemeinsame Logik hinter den Kapiteln und zeigt, welche Schritte Versicherer jetzt konkret gehen sollten, damit „VAIT-konform“ nicht auf dem Papier endet, sondern im Alltag wirkt.
Einordnung · 6. November 2026. VAIT und KAIT wurden mit Ablauf des 16. Januar 2025 aufgehoben. Die frühere nationale IT-Aufsicht wird hier historisch erläutert; für den heutigen Anwendungsbereich ist insbesondere DORA zu prüfen. BAIT/DORA bei der Deutschen Bundesbank.
Warum VAIT? Vom Nebenprozess zur Steuerungsaufgabe
Versicherung ist Informationsverarbeitung: Tarifierung, Bestandsführung, Leistungsprüfung, Meldewesen – alles beruht auf Daten, Anwendungen und vernetzten Prozessen. Störungen sind daher nicht nur IT-Probleme, sondern Geschäftsrisiken. Genau hier setzt VAIT an. Das Rundschreiben übersetzt die bekannten Grundsätze guter Geschäftsorganisation in die IT-Wirklichkeit des Versicherers: verantwortliche Leitung, risikobasierte Steuerung, nachweisbare Wirksamkeit. Die Ausrichtung ist prinzipienorientiert und proportional: Es gibt Ziele und Mindeststandards, aber keine Einheitscheckliste. Tiefe und Taktung richten sich nach Geschäftsmodell, Komplexität und Kritikalität.
Einordnung im Aufsichtsrahmen
VAIT ist Konkretisierung, keine Konkurrenz zu bestehenden Governance-Vorgaben. Es schließt die Lücke zwischen allgemeiner Organisationspflicht und betrieblicher Realität von IT-Betrieb, Entwicklung und Auslagerungssteuerung. Die Botschaft: Leitungsgremium und Schlüsselfunktionen (insbesondere Risikomanagement, Compliance und Interne Revision) müssen IT-Risiken nachvollziehbar in ihre Steuerung aufnehmen. VAIT liefert dafür die Struktur und benennt, wo Nachweise zu erwarten sind.
Die Kapitel in der Übersicht: Sieben Felder, ein Prozess
VAIT zeichnet eine Prozesskette von der Strategie bis zur Auslagerung. Die Bezeichnungen variieren, die Logik ist durchgängig:
- IT-Strategie und Governance
Leitungsorgan, Entscheidungsgremien, Rollen und Mandate. Zielarchitektur, Sourcing-Grundsätze, Leitplanken für Cloud und Standardisierung.
- IKT-Risikomanagement
Vollständige Inventur kritischer Prozesse und Assets, Schutzbedarfe (Vertraulichkeit, Integrität, Verfügbarkeit), Bewertung wesentlicher Risiken, Maßnahmenplanung, Monitoring.
- Informationssicherheitsmanagement
Organisation mit ausreichender Unabhängigkeit, Richtlinienwerk, Kennzahlen, Schulung, Vulnerability- und Patch-Prozesse, Logging/Monitoring, Incident-Handling, Notfallvorsorge.
- Identitäts- und Berechtigungsmanagement
End-to-End-Prozess von Eintritt bis Austritt, Funktionstrennung, Privilegien-Kontrolle, Notfallzugriffe, regelmäßige Rezertifizierungen, technische Durchsetzung.
- Entwicklung und Veränderungswesen
Trennung von Dev/Test/Prod, Freigaben, Rückfallpläne, reproduzierbare Builds, Testabdeckung, Qualitätssicherung; auch Parametrisierung von Standards im Fokus.
- IT-Betrieb und Notfallmanagement
Monitoring, Kapazität, Konfigurations- und Patch-Steuerung, Datensicherung; geprobte Wiederherstellung mit Integritätsnachweis und gelebte Krisenorganisation.
- Auslagerungen und sonstiger Fremdbezug
Due Diligence, Vertragsinhalte (Melde-/Prüf-/Informationsrechte, Datenlokation, Subdienstleister-Transparenz, Exit/Portabilität), laufendes Monitoring, Register und Scorecards.
Die Kapitel sind keine Silos. VAIT erwartet Kohärenz: Was das Risikoregister behauptet, muss zu Testberichten, Vorfallchronik und Auslagerungsverträgen passen.
IT-Strategie & Governance: Verantwortung sichtbar machen
Eine IT-Strategie ist kein Feature-Katalog. Erwartet wird ein dokumentiertes, vom Leitungsorgan gebilligtes Zielbild mit Architekturprinzipien, Sourcing-Grundsätzen und Risikotoleranzen. Kernelemente:
- Entscheidungswege und Gremien: Wer entscheidet was, auf Basis welcher Unterlagen, in welchen Zyklen?
- Mandate: Sicherheitsorganisation mit Eskalationsrecht; klare Verantwortliche für Berechtigungen, Notfall, Auslagerungen.
- Messbarkeit: Kennzahlen und Reviews, die Fortschritt und Wirksamkeit zeigen – nicht nur Vorhabenlisten.
Praxisnahe Strategie heißt: Prioritäten benennen (welche Fähigkeiten sind strategisch), Trade-offs erklären (z. B. Standardisierung vs. Flexibilität) und Risikogrenzen festlegen (z. B. RTO/RPO je Serviceklasse).
IKT-Risikomanagement: Von der Inventur zur Entscheidung
Steuern kann nur, wer bestandsklar ist. Ausgangspunkt ist eine Inventarisierung der kritischen Geschäftsprozesse und ihrer IT-Unterstützung: Anwendungen, Schnittstellen, Plattformen, Datenbestände, Abhängigkeiten – inklusive externer Dienstleister. Darauf aufbauend:
- Schutzbedarfe (C-I-A) je Asset/Prozess.
- Risikobewertung: Eintrittswahrscheinlichkeit, potenzieller Schaden, bestehende Kontrollen, Wirksamkeit.
- Maßnahmenpläne mit Verantwortlichen, Fristen, Priorisierung.
- Kennzahlen und Schwellenwerte, die Alarm und Eskalation auslösen.
Risikomanagement ist dynamisch: Releases, Auslagerungen, neue Angriffsarten verändern das Bild. VAIT erwartet laufende Pflege, nicht Jahresschluss-Prosa.
Informationssicherheitsmanagement: System statt Produkt
Sicherheit ist ein Managementsystem, keine Einkaufsliste. Erwartet werden:
- Organisation & Unabhängigkeit: Informationssicherheitsbeauftragte/r (oder -funktion) mit direkter Berichtslinie, ausreichend Ressourcen, klaren Mandaten.
- Regelwerk & Schulung: schlanke, verbindliche Richtlinien; regelmäßige Sensibilisierung adressatengerecht (Fachbereich, Entwickler, Admin).
- Schwachstellen & Patching: definierte Zyklen, Age-KPIs, Priorisierung nach Kritikalität, Nachweis der Schließung.
- Logging/Monitoring & Use-Cases: was, wo, wie lange – und wozu? Erkennungsregeln, Abdeckung kritischer Szenarien.
- Incident-Handling: Klassifikation, Erst-/Zwischen-/Abschlussberichte, Trennung Fakten/Hypothesen, Chain-of-Custody, Lessons Learned.
- Notfall & Wiederherstellung: Pläne und Übungen mit Erfolgskriterien (RTO/RPO), Integritätsnachweis (Checksummen, Transaktionskohärenz), Re-Tests.
VAIT misst Wirksamkeit, nicht Policy-Dichte. Zahlen zählen: Erkennungszeiten, Schließzeiten, Restore-Erfolgsquote, Use-Case-Abdeckung.
Identitäten & Berechtigungen: End-to-End und prüfbar
Typische Sollbruchstelle: verwaiste Rechte, überbreite Profile, unkontrollierte Admin-Konten. VAIT verlangt:
- Rollenmodelle mit dokumentierter Funktionstrennung.
- Vergabeprozesse mit Vier-Augen-Prinzip und Begründung.
- Privilegien-Kontrolle: Admin-Jump-Hosts, Sitzungsprotokollierung, befristete Notfallrechte.
- Rezertifizierungen in festem Takt, adressatengerecht (Führungskraft, Applikations-Owner).
- Technische Durchsetzung: zentrale Verzeichnisdienste, angebundene Systeme, keine Excel-Schattenverwaltung.
- Nachweise: Populationsbeschreibungen, Stichproben, Widerrufe nach Organisationswechseln.
Ziel ist Nachvollziehbarkeit und Minimierung: so wenig wie möglich, so viel wie nötig – systemisch belegt.
Entwicklung & Change: Qualität sichern, Tempo halten
Versicherer leben in hybriden Landschaften: Host und Web, Standard und Eigenentwicklung, Kern- und Satellitensysteme. VAIT fordert:
- Trennung Dev/Test/Prod, reproduzierbare Builds, nachvollziehbare Konfigurationen.
- Qualitätssicherung: Peer-Reviews, Testabdeckung, definierte Abnahmekriterien inkl. Sicherheitsanforderungen.
- Freigaben & Rückfallpläne, Wartungsfenster, Änderungsjournal.
- Parametrisierung als gleichwertiger Change: Freigabe- und Testtiefe analog zum Code.
- Nachführung von Doku: Anforderungen → Tests → Abnahme – geschlossen, nicht fragmentiert.
Wichtige Brücke: Risiko- und Sicherheitsanforderungen müssen in die Definition of Done – nicht in die Nachsorge.
IT-Betrieb & Notfall: Wiederherstellbarkeit ist kein Gefühl
„Backup vorhanden“ genügt nicht. VAIT erwartet geprobten Wiederanlauf:
- Restore-Tests mit Integritätsnachweis auf Anwendungsebene (nicht nur Datei-Restore).
- Messung gegen definierte RTO/RPO je Serviceklasse; Ergebnis dokumentiert, Abweichungen analysiert, Re-Tests terminiert.
- Betriebsdisziplin: Monitoring/Alarmierung, Kapazitätsmanagement, Konfigurations- und Patch-Steuerung, Härtung, Standardisierung.
- Krisenorganisation: Eskalationswege, Kommunikationsleitfäden, Vertretungsregelungen, Entscheidungsrechte – geübt, nicht nur beschrieben.
Frage in der Prüfung: Wie lange dauert der Wiederanlauf – mit welchem Datenstand – wovon belegt?
Auslagerungen & Fremdbezug: Steuerung statt Hoffnung
Die Lieferkette ist Teil der IT. VAIT verlangt Steuerungsfähigkeit:
- Due Diligence: fachlich, technisch, finanziell; Risiko und Kritikalität.
- Verträge: Informations-/Prüfungsrechte, Meldepflichten bei Vorfällen, Datenlokation, Subdienstleister-Transparenz/-Genehmigung, Exit/Portabilität, Sicherheitsanforderungen.
- Register aller wesentlichen Fremdbezüge mit Kritikalität, Ergebnissen, Terminen.
- Monitoring: Berichte und wo möglich Telemetrie, Audits/Assessments, Scorecards, Eskalationsmechanik.
- Exit-Fähigkeit: Exportformate, Daten- und Betriebs-Escrow, Übungen in angemessenem Zuschnitt.
Wichtig ist die Unterscheidung zwischen Auslagerung und sonstigem Fremdbezug – beides gehört gesteuert, die Tiefe richtet sich nach Wesentlichkeit.
Proportionalität richtig leben
Proportionalität heißt fokussieren, nicht weglassen. Beispiele:
- Kompositer mit großer Maklerstrecke: Schwerpunkt auf Identitäten/Berechtigungen, Integrität von Schnittstellen, Verfügbarkeit von Angebots- und Bestandsprozessen, geübte Notfallkommunikation.
- Lebensversicherer mit Langzeithaltung: Datenintegrität und Nachvollziehbarkeit, Archivierungs- und Restore-Nachweise, Entwicklung/Parametrisierung im Aktuariat besonders streng.
- Direktversicherer mit hohem SaaS-Anteil: Auslagerungssteuerung, Portabilität/Exit-Tests, technische Telemetrie aus der Lieferkette, API-Sicherheit.
Entscheidend ist die Begründung aus Schutzbedarf und Business Impact.
Kennzahlen & Nachweise: Was zählt
VAIT-Prüfungen sind evidenzbasiert. Typische Nachweise:
- Systemexporte (GRC/CMDB/Monitoring) mit Metadaten und Zeitstempeln, nicht manuelle Listen.
- Risikoregister mit Maßnahmenstatus, Management-Beschlüssen.
- KPIs/KRIs: Erkennungs-/Behebungszeiten, Patch-Alter, Use-Case-Abdeckung, Restore-Erfolgsquote, Rezertifizierungsquote, SLA-Erfüllung kritischer Dienstleister.
- Incident-Chroniken: Erst/Zwischen/Abschluss, Fakten/Hypothesen, RCA, Lessons Learned → umgesetzte Maßnahmen.
- Testberichte: Akzeptanzkriterien, Messergebnisse, Abweichungen, Re-Tests.
- Auslagerungsdossiers: Verträge/Nachträge, Scorecards, Auditergebnisse, Subdienstleister-Ketten, Exit-Proben.
Wichtig: Kohärenz prüfen – stimmen die Zahlen über alle Quellen hinweg?
Typische Fallstricke – und Gegenmittel
- Papier-Notfall ohne Restore-Evidenz → Standardisierte Restore-Schemata, Integritätsnachweis, Re-Tests.
- Berechtigungen ohne Ende-zu-Ende → Rollen, Funktionstrennung, technische Durchsetzung, Rezertifizierung mit Stichproben.
- Auslagerungsregister veraltet → Änderungstrigger (neuer Subdienstleister, Standortwechsel, Architekturänderung, Major Incident), monatliche Pflege, quartalsweise Qualitätssicherung.
- Vulnerability-„Staus“ → Priorisierung nach Kritikalität, definierte Schließzeiten, Ausnahmen nur mit befristeter Genehmigung und Kompensation.
- Inkonsistenzen zwischen Risiko, Tests, Incidents und Verträgen → Kohärenz-Review pro Quartal mit verbindlicher Abstellung.
Roadmap: Vom Projekt zur Routine
- Transparenz schaffen: vollständige Inventarisierung kritischer Prozesse/Assets, Schutzbedarfe, Abhängigkeiten.
- Governance festziehen: Rollen/Mandate, Gremien, Berichtswege; Sicherheitsorganisation mit Eskalationsrecht.
- Risikobasiert priorisieren: Top-Risiken und kritische Services, Maßnahmenbündel, Testkalender mit Akzeptanzkriterien.
- Auslagerungen schärfen: Vertragsnachträge (Melde-/Prüf-/Exit-Rechte, Sub-Outsourcing), Register-Qualität, Scorecards, where possible Telemetrie.
- Evidenz-Baukasten etablieren: systemseitige Exporte, Versionierung, Unveränderlichkeit (WORM/Hash), Populations- und Stichprobenlogik.
- Probe-Audit: Operating-Effectiveness-Fokus, Findings in CAPA-Plan, Re-Tests.
- Routine sichern: monatliche Evidence-Tage, quartalsweise Management-Reviews mit Kennzahlen statt Folien, jährliche Notfall- und Exit-Übungen.
Fazit: VAIT als Betriebsanleitung – nicht als Hürde
VAIT ist kein zusätzlicher Papierberg, sondern die Betriebsanleitung für eine beherrschte, nachweisbare und resiliente IT im Versicherungsunternehmen. Wer die gemeinsamen Leitplanken ernst nimmt, gewinnt: weniger Ausfälle, schnellere Wiederherstellung, klarere Verantwortungen, belastbare Verhandlungsposition gegenüber Dienstleistern, weniger Überraschungen in Prüfungen. Der Schlüssel liegt in der Routine: Prozesse so bauen, dass Evidenz als Nebenprodukt entsteht – konsistent, versioniert, auskunftsfähig. Dann wird VAIT nicht zur Zwangsjacke, sondern zum Rahmen, in dem sich ein Versicherer stabil, effizient und prüfbar entwickelt.
Den historischen VAIT-Ansatz in die heutige Steuerung übertragen. Nutzen Sie eine damalige Kontrollaufgabe als Ausgangspunkt und prüfen Sie ihre heutige regulatorische Zuordnung. Bereits wirksame Prozesse können weiterhelfen, ihre Referenzen und Nachweise müssen jedoch zum geltenden Rahmen passen.
Regulatorische Anforderungen entfalten ihren Nutzen erst, wenn sie in Verantwortung, Prozesse und Kontrollen überführt werden. Das Buch beleuchtet diesen Übergang aus einer Management- und Governance-Perspektive.
Von Dr. Markus Groß
Comments 33
Eine Frage zur Umsetzung: wie Transparenz, Verantwortung und praktische Nutzbarkeit zusammengebracht werden. Welche Beobachtung wäre wichtiger als eine reine Vollständigkeitsquote?
Entscheidend wäre für mich, nicht nur die Durchführung zu dokumentieren. Auch die Wirkung und eine mögliche Abweichung sollten später nachvollziehbar sein.
Den Pilotgedanken finde ich gut. Ergänzen würde ich eine klare Schwelle: Ab wann führt das Ergebnis zu einer Entscheidung und wann bleibt es nur eine Beobachtung?
Genau diese Verbindung ist entscheidend: klein beginnen, aber Wirkung und Entscheidungsfolge vorher festlegen. So bleibt der Aufwand vertretbar und das Ergebnis trotzdem belastbar.
So ergibt die Vorgehensweise Sinn: begrenzter Einstieg, klare Messgröße und eine sichtbare Entscheidung, falls das Ergebnis nicht trägt.
Eine Frage zur Umsetzung: Wie würdest du die im Beitrag angesprochenen Anforderungen in überschaubare erste Schritte übersetzen?
Ich würde mit klaren Verantwortlichkeiten und einem begrenzten Anwendungsfall beginnen. So lässt sich prüfen, ob die Vorgehensweise im Alltag tatsächlich hilft.
Welche Rolle sollte bei der nachvollziehbaren Umsetzung die betroffene Fachseite bei der ersten Bewertung des Ergebnisses spielen? Damit wäre der nächste Entscheidungspunkt klarer. Das sollte möglichst im normalen Arbeitsablauf sichtbar werden.
Wie geht man mit sich verändernden aufsichtsrechtlichen Rahmenbedingungen um?
Ich würde es so einordnen: Ich würde die fachlichen Anforderungen und ihre Einordnung getrennt prüfen. Ein geänderter Rahmen kann eine Neubewertung verlangen; bestehende wirksame Abläufe müssten dadurch nicht pauschal verworfen werden.
Ich lese das etwas anders. Für mich steht zuerst die Frage im Raum, ob der zugrunde liegende Bedarf überhaupt ausreichend geklärt ist.
Für mich müsste sich zunächst erklären lassen, welche Entscheidung verbessert werden soll. Daraus würde ich den notwendigen Umfang ableiten, statt mit der maximalen Dokumentation anzufangen. Auf die Ausgangsfrage bezogen: Ich würde die fachlichen Anforderungen und ihre Einordnung getrennt prüfen. Ein geänderter Rahmen kann eine Neubewertung verlangen; bestehende wirksame Abläufe müssten dadurch nicht pauschal verworfen werden.
Damit kann ich mehr anfangen. Die Grenze zwischen einem hilfreichen Nachweis und zusätzlichem Papier bleibt für mich der entscheidende Punkt. Die Ausgangsfrage „Wie geht man mit sich verändernden aufsichtsrechtlichen Rahmenbedingungen um?“ ist damit für mich noch nicht vollständig beantwortet.
Wie würdet ihr Nachvollziehbarkeit der Kontrollnachweise konkret prüfen, wenn ein Dienstleister einen Teil der Umsetzung übernimmt?
Für diesen Fall wäre mein Ansatz: die erwarteten Ergebnisse und Übergaben konkret vereinbaren; ein Vertrag allein belegt noch keine Umsetzung. Damit bleibt sichtbar, was entschieden wurde und was noch offen ist. Bei Nachvollziehbarkeit der Kontrollnachweise sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Wie würdet ihr bei Nachvollziehbarkeit der Kontrollnachweise die wichtigsten Abhängigkeiten für die Umsetzung sichtbar machen?
Ich würde zunächst die wenigen Abhängigkeiten erfassen, deren Ausfall oder Verzögerung das Ergebnis tatsächlich gefährdet. Die Liste sollte eine Entscheidung ermöglichen und regelmäßig überprüft werden. Für Nachvollziehbarkeit der Kontrollnachweise würde ich den ersten Prüfschritt bewusst klein halten.
Wo würdet ihr bei Behandlung von Ausnahmen und Abweichungen anfangen, wenn unter Zeitdruck eine Ausnahme erforderlich wird?
Ich würde zunächst die Ausnahme befristen und mit einem benannten Verantwortlichen sowie einer späteren Überprüfung verbinden. Das schafft eine begrenzte, überprüfbare Arbeitsgrundlage für die weitere Umsetzung. Bei Behandlung von Ausnahmen und Abweichungen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Ergänzend würde ich den Blick auf Nachvollziehbarkeit automatisierter Entscheidungen richten. Welche Mindestinformation wird dafür im Alltag wirklich benötigt?
Ein weiterer Punkt: Wie viel Einheitlichkeit ist bei unterschiedlichen Unternehmen und Geschäftsmodellen sinnvoll?
Für mich wäre ein gemeinsamer Kern hilfreich. Die konkrete Ausgestaltung müsste aber die tatsächlichen Leistungen und Risiken berücksichtigen.
Ich finde den Ansatz plausibel, aber noch sehr grundsätzlich. An welchem konkreten Entscheidungspunkt würde er einen Unterschied machen? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ich würde das Ergebnis vorher festlegen: Was soll danach klarer, schneller oder belastbarer sein? Ohne diesen Bezug ist der Erfolg einer Änderung schwer zu beurteilen. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Genau an der Übergabe sehe ich ebenfalls die Schwierigkeit. Ohne die nötige Information kann auch eine klar benannte Person wenig entscheiden. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Wie verhindert man, dass IT-Governance hauptsächlich an einer Dokumentenliste ausgerichtet wird?
Das ist ein wichtiger Punkt. Ich würde den Betrieb und seine Entscheidungen als Ausgangspunkt nehmen. Dokumentation sollte die Verantwortlichkeiten und Kontrollen erklären, nicht deren Ersatz sein.
Könnte diese Lösung nicht gerade bei kleinen Teams zu viel Aufwand verursachen? Ich würde die Mindestanforderung deutlicher abgrenzen. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ich würde die Ausnahme nicht verstecken, sondern mit Begründung, zuständiger Person und Prüfanlass festhalten. Dann kann man auch später erkennen, ob die Grundlage noch gilt. Auf die Ausgangsfrage bezogen: Ich würde den Betrieb und seine Entscheidungen als Ausgangspunkt nehmen. Dokumentation sollte die Verantwortlichkeiten und Kontrollen erklären, nicht deren Ersatz sein.
Ja, so wird die Abwägung konkreter. Ich würde vor allem den Prüfanlass festhalten, damit die Lösung nicht unbegrenzt als gesetzt gilt. Die Ausgangsfrage „Wie verhindert man, dass IT-Governance hauptsächlich an einer Dokumentenliste ausgerichtet wird?“ ist damit für mich noch nicht vollständig beantwortet.
Ich finde den Ansatz plausibel, aber noch sehr grundsätzlich. An welchem konkreten Entscheidungspunkt würde er einen Unterschied machen? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Wie verhindert ihr bei Behandlung von Ausnahmen und Abweichungen, dass eine vorläufige Lösung ohne erneute Prüfung dauerhaft bestehen bleibt?
Ich würde einen festen Wiedervorlagetermin und eine klare Entscheidung über Fortführung oder Abschluss vorsehen. Wichtig ist, dass die Ausnahme nicht allein deshalb bestehen bleibt, weil niemand mehr nachfragt. Mit Blick auf Behandlung von Ausnahmen und Abweichungen würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.