Fünf Kernschritte, ein Datenmodell: wie ein Projekt in CIVAC vom Geltungsbereich zum Bericht läuft, und an welcher Stelle kein Modell beteiligt ist

Wichtige Erkenntnisse

• Sieben Falltypen laufen über dasselbe Modell: Datenschutz-Folgenabschätzung, Transfer Impact Assessment, Lieferantenaudit, TOM-Prüfung, externe DSFA, Audit und Vorfallbearbeitung. Die fünf Kernschritte sind für alle gleich; was sich unterscheidet, ist die Vorlage, aus der der Bericht entsteht.
• Jeder Kernschritt hat drei Zustände, offen, in Arbeit, erledigt, und der Fall selbst vier: neu, in Bearbeitung, Bericht entworfen, abgeschlossen. Der Fortschritt eines Projekts ist die Zahl der erledigten Kernschritte, nicht eine Einschätzung.
• Beim Anlegen eines Projekts erzeugt ein Sprachmodell aus dem Geltungsbereich und den Dateinamen der Unterlagen drei bis fünf Startrisiken und drei bis fünf Startfragen. Der Inhalt der Dateien wird dabei nicht gelesen; das geschieht erst, wenn die Unterlagen hochgeladen und ausgewertet sind.
• Der dritte Schritt, Rückfragen beantworten und Risiken bearbeiten, ist der einzige, an dem kein Modell beteiligt ist. Er ist zugleich der Schritt, der den Bericht projektspezifisch macht: Die Antworten und die Risikoliste gehen wörtlich in die Berichtsvorlage ein.
• Der Bericht ist ein Entwurf mit Zähler. Jede Erzeugung erhöht die Iteration, und ein Prüfsummenvergleich der Eingaben markiert den Bericht als veraltet, sobald sich eine Antwort oder ein Risiko nach der letzten Erzeugung geändert hat.
• CIVAC ist keine Kanzlei. Der Bericht ist organisatorische Unterstützung mit Quellenangabe; ob eine Verarbeitung zulässig ist, ob ein Risiko tragbar ist und ob der Bericht unterschrieben wird, entscheidet die bestellte Person oder das Unternehmen.

Was ein Projekt technisch ist

In der Oberfläche heißt es Projekt, im Datenmodell heißt es Fall. Ein Fall hat genau einen Typ aus einer festen Liste von sieben: Datenschutz-Folgenabschätzung, Transfer Impact Assessment, Lieferantenaudit, TOM-Prüfung, externe DSFA, Audit und Vorfallbearbeitung. Diese Liste ist im Modell hinterlegt und nicht frei erweiterbar; wer einen achten Typ braucht, wählt den nächstliegenden und passt Vorlage und Sonderaufgaben an. Der Typ entscheidet vor allem darüber, welche Vorlage aus der Mastersheet-Bibliothek den Bericht formt, und er löst bei der Vorfallbearbeitung eine Benachrichtigung aus, sobald ein neuer Fall dieses Typs angelegt wird.

Unabhängig vom Typ hat jeder Fall dieselben fünf Kernschritte in derselben Reihenfolge: Geltungsbereich, Unterlagen, Rückfragen, Risiken, Bericht. Jeder Schritt trägt einen von drei Zuständen, offen, in Arbeit oder erledigt, mit Zeitstempel der letzten Änderung. Der Fall selbst kennt vier Zustände: neu, in Bearbeitung, Bericht entworfen, abgeschlossen. Der Fortschritt, den die Projektliste anzeigt, ist die Anzahl der erledigten Kernschritte. Er wird gezählt, nicht geschätzt.

Schritt eins: der Geltungsbereich

Der Geltungsbereich besteht aus vier Textfeldern und einer Liste. Die Felder heißen Werkzeug, Bereich, Zweck und Beschreibung: Welches System oder welcher Prozess wird betrachtet, in welcher Abteilung, zu welchem Zweck, und was ist in eigenen Worten der Gegenstand. Die Liste enthält die beteiligten Personen. Eine beteiligte Person ist entweder ein Mitglied der Organisation mit Nutzerkennung oder ein externer Kontakt, der nur mit Namen und optional mit E-Mail-Adresse erfasst wird, etwa ein Lieferant oder ein externer Prüfer.

Sobald der Geltungsbereich ausgefüllt ist, geschieht beim Anlegen des Projekts das Erste, was ein Sprachmodell in diesem Ablauf tut: Aus den vier Feldern und, falls schon Unterlagen angegeben sind, aus deren Dateinamen und Etiketten erzeugt es drei bis fünf Startrisiken und drei bis fünf Startfragen. Der Inhalt der Dateien wird an dieser Stelle nicht gelesen. Wenn für den gewählten Typ eine Vorlage mit hinterlegten Risiken und Fragen existiert, hat diese Vorlage Vorrang vor dem Modell; wenn der Modellaufruf fehlschlägt, werden feste Startlisten eingesetzt, damit das Projekt nicht leer beginnt. Diese Reihenfolge, Vorlage vor Modell vor fester Liste, ist im Code festgelegt.

Schritt zwei: die Unterlagen

Jede Unterlage wird mit einem von sechs Etiketten abgelegt: Vertrag, TOM, Lieferantendokument, Prozess, Richtlinie oder Notiz. Neben Dateiname, Zeitpunkt, hochladender Person und Größe trägt sie einen Verarbeitungszustand, der vier Werte durchläuft: ausstehend, hochgeladen, in Auswertung, bereit; ein fünfter Wert, fehlgeschlagen, hält fest, wenn die Auswertung nicht gelungen ist. Bereit bedeutet, dass der Text der Datei ausgelesen und in Abschnitte zerlegt in der Datenbank liegt. Erst in diesem Zustand kann ein Modell den Inhalt für Vorschläge verwenden; bis dahin existiert die Datei für das Modell nur als Name und Etikett.

Aus bereiten Unterlagen kann die Beauftragte zwei Dinge anfordern, beide optional: eine Lückenerkennung, die zusätzliche Rückfragen vorschlägt, und eine Risikoextraktion, die Risiken aus dem Text der Unterlagen vorschlägt. Beides sind Vorschläge, die als solche in die Listen der Schritte drei und vier eingetragen werden und dort bearbeitet oder gelöscht werden können. Die Systemanweisung für beide Aufrufe wird aus der Vorlage des Projekts abgeleitet, also aus Rolle, Anwendungsfall und Quellen, damit ein Lieferantenaudit nicht mit den Fragen einer Datenschutzprüfung angereichert wird.

Schritt drei: die Rückfragen, ohne Modell

Eine Rückfrage trägt den Fragetext, optional einen Adressaten, eine Priorität aus drei Stufen, blockierend, wichtig oder wünschenswert, und eine Begründung, warum sie für dieses Projekt relevant ist. Ihr Zustand ist offen oder beantwortet. Das Beantworten ist eine Eingabe durch einen Menschen, und es ist der einzige Kernschritt, an dem kein Modell beteiligt ist. Es ist zugleich der Schritt, der den späteren Bericht projektspezifisch macht: Beantwortete Fragen werden mit ihrer Antwort wörtlich in den Kontext eingesetzt, aus dem der Bericht erzeugt wird. Eine unbeantwortete blockierende Frage ist deshalb keine Formalie, sondern eine Lücke im Bericht, die die Vorlage nicht schließt.

Schritt vier: die Risiken

Ein Risiko trägt einen Titel, eine Eintrittswahrscheinlichkeit und eine Auswirkung, jeweils in drei Stufen, niedrig, mittel, hoch, optional eine Maßnahme und eine Kategorie, und ein Herkunftsfeld mit genau zwei Werten: manuell oder vom Modell vorgeschlagen. Dieses Feld bleibt am Risiko, auch wenn es später bearbeitet wird; ein vorgeschlagenes Risiko wird durch Bearbeitung nicht zu einem manuellen. Hinzufügen, Ändern und Entfernen sind wie in Schritt drei reine Eingaben. Alle Risiken, mit Wahrscheinlichkeit, Auswirkung und Maßnahme, gehen in den Kontext des Berichts ein.

Schritt fünf: der Bericht, mit Zähler

Der Bericht wird nicht aus einem festen Text erzeugt, sondern aus einer zur Laufzeit zusammengesetzten Anweisung: der Vorlage aus der Mastersheet-Bibliothek, dem Kontext des Falls, also Geltungsbereich, beantworteten Fragen und Risiken, und einem Formatblock, der die Berichtsart festlegt. Die Vorlage wird in dieser Reihenfolge bestimmt: eine ausdrücklich gewählte Vorlage, sonst eine Vorlage, deren Stichworte zum Falltyp passen, sonst die erste Auditvorlage der Rolle, sonst die Standardvorlage für eine Datenschutz-Folgenabschätzung. Freitextberichte werden gestreamt, sodass der Entwurf beim Entstehen lesbar ist; strukturierte Berichtsarten wie Schulung, Checkliste, Protokoll oder Matrix werden gegen ein festes Schema erzeugt.

Zwei Mechanismen machen den Bericht nachvollziehbar. Erstens wird mit jeder Erzeugung ein Zähler erhöht und die Liste der verwendeten Quellen gespeichert, zusammen mit der Kennung der Vorlage. Zweitens berechnet das System eine Prüfsumme über die Eingaben des Berichts. Ändert sich nach der letzten Erzeugung eine Antwort oder ein Risiko, stimmt die Prüfsumme nicht mehr, und der Bericht wird in der Oberfläche als veraltet angezeigt, mit dem Hinweis, dass sich die Eingaben geändert haben. Der alte Entwurf verschwindet dadurch nicht; er ist nur nicht mehr der Stand der Eingaben.

Sonderaufgaben neben den Kernschritten

Was nicht in die fünf Schritte passt, wird als Sonderaufgabe geführt: mit Titel, Beschreibung, Zustand, Fälligkeit, eigenen Unterlagen, Notizen und einer zugewiesenen Person, die wie im Geltungsbereich ein Mitglied oder ein externer Kontakt sein kann. Eine Sonderaufgabe kann eine Checkliste tragen; dann liest der Fall ihren Fortschritt als Anteil der abgehakten Punkte. Sonderaufgaben ändern nichts am Zustand der Kernschritte, sie laufen daneben.

Was das für die Beauftragte bedeutet

Wer weiß, wo im Ablauf ein Modell arbeitet und wo nicht, kann die eigene Zeit gezielt einsetzen. Die Startlisten sind ein Angebot, keine Prüfung: Sie entstehen aus vier Textfeldern und Dateinamen. Die Vorschläge aus den Unterlagen sind nur so gut wie die Unterlagen, die den Zustand bereit erreicht haben. Der Bericht ist nur so spezifisch wie die Antworten in Schritt drei. Und die Markierung als veraltet ist keine Störung, sondern der Hinweis, dass der Bericht neu erzeugt werden sollte, bevor er exportiert wird.

Was das Modell an keiner Stelle tut: entscheiden. CIVAC ist keine Kanzlei und erteilt keine Rechtsberatung im Einzelfall. Ob eine Verarbeitung zulässig ist, ob ein Risiko tragbar ist, ob eine Maßnahme ausreicht und ob der Bericht in dieser Form unterschrieben wird, entscheidet die bestellte Person beziehungsweise das Unternehmen. Der Bericht ist organisatorische Unterstützung mit Quellenangabe. Wo eine Frage eine rechtliche Bewertung im Einzelfall verlangt, gehört sie zur Rechtsabteilung oder zu einer Kanzlei.

Welche Projekttypen gibt es in CIVAC?

Sieben, fest im Datenmodell hinterlegt: Datenschutz-Folgenabschätzung, Transfer Impact Assessment, Lieferantenaudit, TOM-Prüfung, externe DSFA, Audit und Vorfallbearbeitung. Alle sieben laufen über dieselben fünf Kernschritte; der Typ bestimmt vor allem die Berichtsvorlage.

An welchen Stellen arbeitet ein Sprachmodell?

An drei: beim Anlegen, wo aus Geltungsbereich und Dateinamen Startrisiken und Startfragen entstehen; optional bei bereiten Unterlagen, wo zusätzliche Fragen und Risiken aus dem Dokumenttext vorgeschlagen werden; und beim Bericht, der aus Vorlage und Fallkontext erzeugt wird. Das Beantworten der Rückfragen und das Bearbeiten der Risiken sind reine Eingaben.

Liest das Modell beim Anlegen meine Dateien?

Nein. Beim Anlegen gehen nur Dateiname und Etikett in den Aufruf ein. Der Text einer Datei wird erst verwendet, wenn sie hochgeladen und ausgewertet ist, also den Zustand bereit erreicht hat, und auch dann nur, wenn eine Lückenerkennung oder Risikoextraktion angefordert wird.

Warum steht am Bericht plötzlich, dass er veraltet ist?

Weil sich seit der letzten Erzeugung eine Antwort oder ein Risiko geändert hat. Das System vergleicht eine Prüfsumme der Eingaben mit dem Stand der letzten Erzeugung. Der alte Entwurf bleibt erhalten; die Markierung sagt, dass er nicht mehr den aktuellen Eingaben entspricht.

Ist der erzeugte Bericht eine rechtliche Bewertung?

Nein. Er ist ein Entwurf aus Vorlage, Antworten und Risiken, mit Angabe der verwendeten Quellen. Die Bewertung, ob etwas zulässig oder tragbar ist, und die Unterschrift liegen bei der bestellten Person oder dem Unternehmen; CIVAC ist keine Kanzlei.