Semantic Web · Compliance · Artikel 3 · Entwurf

Compliance als Graph, nicht als Tabellenkalkulation

Fragt man ein Compliance-Team, wie eine Anforderung erfüllt wird, bekommt man oft eine Führung durch Tabellen. Eine Tabelle listet die Anforderungen. Eine andere die Kontrollen. Eine dritte enthält die Nachweise, eine vierte die Risiken, und die Audit-Feststellungen stehen in einem Bericht. Die Antwort existiert, aber jemand muss die Tabellen von Hand zusammenführen, und die nächste Person wird es wieder tun.

Die Idee hinter dem Semantic Web bietet eine andere Art, dieselben Informationen zu halten.

Die Idee in einfachen Worten

Die Idee des Semantic Web ist, Daten als verknüpfte, maschinenlesbare Aussagen zu veröffentlichen: Dieses Ding steht in dieser Beziehung zu jenem Ding. Jedes Ding hat eine eigene Identität, und die Beziehungen sind Teil der Daten, nichts, was ein Leser erst erschließen muss. Eine Sammlung solcher Aussagen ist ein Wissensgraph.

Für Governance, Risiko und Compliance bedeutet das eine kleine Änderung der Gewohnheit. Eine Anforderung, eine Kontrolle, ein Nachweis, ein Risiko und eine Audit-Feststellung sind keine Zeilen in verschiedenen Listen mehr. Jedes wird zu einem Datensatz mit eigener Identität, und die Verknüpfungen dazwischen werden ebenfalls zu Datensätzen.

Zwei Felder. Links getrennte Listen für Anforderungen, Kontrollen und Nachweise, die Menschen immer wieder von Hand zusammenführen. Rechts verknüpfte Datensätze, in denen jedes Element eine Identität hat und die Beziehungen dazwischen ebenfalls Datensätze sind, sodass die Verknüpfungen erhalten bleiben, statt neu aufgebaut zu werden. Ein Pfeil führt von links nach rechts. — Abbildung 1: von Listen zu verknüpften Datensätzen

Wie eine Kontrolle im Graph aussieht

Nehmen wir eine Kontrolle. Sie erfüllt eine Anforderung. Sie mindert ein Risiko. Sie wird durch einen Nachweis gestützt. Sie wurde in einem Audit getestet, und der Test ergab eine Feststellung. In einem Graph ist jede dieser Aussagen eine Verknüpfung von der Kontrolle zu einem anderen Datensatz, und jede Verknüpfung sagt, wer sie angelegt hat, wann und auf welcher Grundlage.

Oben steht eine Kontrolle. Verknüpfungen führen von ihr zu einer Anforderung, die sie erfüllt, einem Risiko, das sie mindert, einem Nachweis, der sie stützt, und einer Audit-Feststellung aus einem Test der Kontrolle. Ein Band darunter besagt, dass jede Verknüpfung selbst ein Datensatz ist, der sagt, wer sie angelegt hat, wann und auf welcher Grundlage. — Abbildung 2: eine Kontrolle und womit sie verbunden ist

Es braucht nichts Exotisches, um den Nutzen zu sehen. Die Frage „Wie wird diese Anforderung erfüllt, und woher wissen wir es?“ wird zu einem Gang entlang der Verknüpfungen statt zu einer Führung durch Tabellen.

Was das möglich macht

Nachvollziehbarkeit. Von einer Anforderung aus lassen sich die Verknüpfungen zur Kontrolle, zum Nachweis und zum letzten Test verfolgen, und von einer Feststellung zurück zur betroffenen Kontrolle. Die Spur sind die Daten selbst.

Abbildung über Rahmenwerke hinweg. Anforderungen aus verschiedenen Rahmenwerken verlangen oft ziemlich dasselbe. In einem Graph schreibt man die Kontrolle einmal und verknüpft sie mit jeder Anforderung, die sie beantwortet; so bedient ein Datensatz mehrere Quellen, und eine Lücke zeigt sich als Anforderung ohne Kontrolle dahinter.

Ein Datensatz, mehrere Sichten. Weil die Fakten einmal gehalten werden, lässt sich jeder Person der Teil zeigen, der zu ihrer Rolle passt: Die Compliance-Leitung sieht Status und Lücken, der Prüfer sieht Tests und Nachweise, der Risikomanager sieht die Risiken, die die Kontrolle mindert. Niemand führt eine private Kopie.

Oben ein Kontrolldatensatz. Von ihm führen drei Sichten weg: Die Compliance-Leitung sieht Status und Lücken, der Prüfer sieht Tests und Nachweise, und der Risikomanager sieht die Risiken, die er mindert. Der Datensatz wird einmal gehalten, und jede Person sieht den Teil, der zu ihrer Rolle passt. — Abbildung 3: ein Datensatz, mehrere Sichten

„Wie sah das damals aus?“ Zeit ist auf zwei Arten Teil des Modells. Ein Datensatz behält datierte Versionen, und jede Änderung wird zusätzlich als Ereignis erfasst: wer was geändert hat, von welchem Wert zu welchem. Zusammen erlauben sie, den früheren Zustand eines Datensatzes zurückzulesen, sodass Fragen von Prüfern zu einem bestimmten Zeitpunkt keine Archäologie mehr sind.

Eine Zeitleiste von links nach rechts mit einer früheren Version, einer Änderung und der aktuellen Version desselben Datensatzes. Ein Band darunter besagt, dass jede Änderung ein Ereignis ist, das festhält, wer was geändert hat, von welchem Wert zu welchem, sodass der frühere Zustand zurückgelesen werden kann. — Abbildung 4: wie sah es damals aus

Ein Ort, an dem Agenten lesen und schreiben können, mit Gates. Einen Graph können Software-Agenten direkt lesen, weil die Struktur explizit ist. Schreiben ist etwas anderes. Im Sinne der Kontrollen aus dem ersten Artikel dieser Reihe liest ein Agent frei, schlägt Änderungen aber über ein Gate vor: Prüfung, Freigabe durch den Owner und eine Aufzeichnung der Entscheidung. Der Graph bleibt vertrauenswürdig, weil das, was in ihn gelangt, freigegeben und nachvollziehbar ist.

Links ein Agent mit begrenzten Zugangsdaten, der frei aus dem Graph in der Mitte liest. Will er etwas ändern, schlägt er die Änderung einem Gate rechts vor, wo sie auf Prüfung und Freigabe wartet; nur die freigegebene Änderung erreicht den Graph. Ein Band darunter besagt, dass jeder Vorschlag, jede Entscheidung und jede Änderung aufgezeichnet wird. — Abbildung 5: Agenten lesen und schreiben mit Gates

Wo ein Graph gegen eine Tabelle verliert

Ein Graph ist nicht kostenlos, und er ist nicht immer das bessere Werkzeug. Vier ehrliche Kosten:

Pflege. Verknüpfungen müssen angelegt und aktuell gehalten werden. Eine Tabellenzeile ist in einer Minute korrigiert; eine Beziehung muss überall korrigiert werden, wo sie verwendet wird.
Eine veraltete Verknüpfung ist schlimmer als eine veraltete Zeile. Eine veraltete Zeile sieht veraltet aus. Eine veraltete Verknüpfung sieht aus wie ein Fakt, und jede Frage, die ihr folgt, erbt den Fehler mit Überzeugung. Verknüpfungen brauchen eine Quelle, ein Datum und eine Möglichkeit, als abgelöst markiert zu werden.
Pflege des Modells. Ein gemeinsames Vokabular aus Datensatzarten und Verknüpfungstypen hilft nur, solange jemand es verantwortet. Ohne Verantwortlichen driftet es oder wächst, bis niemand es mehr pflegt.
Datenqualität. Ein Graph macht schlechte Daten sichtbarer, nicht besser. Doppelte Datensätze, Freitextnamen und fehlende Kennungen werden zu defekten oder doppelten Verknüpfungen.

Für eine kleine, stabile Frage, die ein Team beantwortet, ist eine Tabelle schneller und billiger. Ein Graph verdient seine Kosten, wenn dieselben Fakten von vielen Menschen und vielen Werkzeugen gelesen werden, wenn Beziehungen wichtiger sind als Zeilen und wenn die Historie beantwortbar sein muss.

Warum er gerade zu diesem Feld passt

Governance, Risiko und Compliance ist ein Feld der Beziehungen: was gefordert ist, was dagegen getan wird, was zeigt, dass es getan wurde, was noch schiefgehen könnte und was eine unabhängige Prüfung festgestellt hat. Tabellen halten die Dinge und überlassen die Beziehungen den Menschen. Ein Graph hält beides, und so verschiebt sich die Arbeit vom Abgleichen zum Lesen.

Er passt auch zur Argumentation dieser Reihe. Harte Kontrollen für Agenten und automatisierbare Compliance hängen beide vom Gleichen ab: expliziten, verknüpften, aufgezeichneten Fakten, denen ein Mensch oder ein Agent folgen und die er prüfen kann.

Fazit

Anforderung, Kontrolle, Nachweis, Risiko und Feststellung als verknüpfte Datensätze führen, jede Änderung als Ereignis aufzeichnen und Agenten frei lesen, aber nur über ein Gate schreiben lassen. Nachvollziehbarkeit, Verlauf und Abbildung ergeben sich dann aus der Struktur, nicht aus Aufwand.