Die wahre Geschichte hinter GRC Engineering (aus der Sicht eines Menschen, der sie selbst erlebt hat)

Vor fünf Jahren war „GRC-Ingenieur“ eine Berufsbezeichnung, die den meisten Compliance-Verantwortlichen unbekannt war. Heute ist sie allgegenwärtig: auf Stellenanzeigen, in Konferenzprogrammen und in den Organigrammen von Unternehmen, die Sicherheit ernst nehmen.

Dies ist die Geschichte, wie es dazu kam, erzählt aus der Perspektive von Kurtes Allen, einem GRC-Ingenieur, dessen Weg in dieses Berufsfeld von denselben Zwängen geprägt war, die die Disziplin insgesamt umgestaltet haben.

Ein Praktiker, der beinahe weggegangen wäre

Kurtes kam auf dem praktischsten Weg zur Cybersicherheit. Er baute seinen ersten Computer, bevor er einen Kurs zum Computerbau besuchte, bekam direkt nach der High School einen Job als IT-Labortechniker und studierte schließlich Telekommunikation an der Universität, bevor er zur Cybersicherheit wechselte.

Dann kam er zum GRC-Modul und hasste es. Es wirkte trocken, überladen mit Frameworks und weit entfernt von den Systemen, mit denen er eigentlich arbeiten wollte. Der Dozent half ihm dabei auch nicht weiter.

„Ich wollte den Kurs einfach nur bestehen und ihn loswerden. Ich hatte nicht die Absicht, später noch einmal auf GRC zurückzublicken.“

So bestand er den Kurs und kehrte zu dem Teil des Sicherheitsdienstes zurück, wo er sich die Hände schmutzig machen konnte.

Diese Reaktion war jedoch nicht ungewöhnlich. Tatsächlich war sie die typische Reaktion der meisten Unternehmen der Branche auf die Compliance-Arbeit zu dieser Zeit. Und zu verstehen, warum, ist der erste Schritt zum Verständnis, warum GRC-Engineering überhaupt entwickelt werden musste.

Die Belastungen, die das alte Modell zum Zusammenbruch brachten

Ende der 2010er Jahre versagte die Einhaltung der Vorschriften auf drei Ebenen gleichzeitig.

Der Anwendungsbereich explodierte. Ein Unternehmen, das über verschiedene Regionen, Kundensegmente und Branchen hinweg agierte, sah sich schnell mit einer Vielzahl von Rahmenwerken konfrontiert, von SOC 2 und ISO 27001 bis hin zu HIPAA, PCI und DSGVO. Die Überschneidungen waren beträchtlich, oft 60 bis 70 Prozent, doch die Zuordnung selbst wurde zu einer Vollzeitbeschäftigung.

Gleichzeitig veränderte sich die Infrastruktur ständig. In einer Welt kontinuierlicher Bereitstellung hatte sich das System, das ein Prüfer im März zertifiziert hatte, im Juni strukturell verändert. Daher sagten die zu einem bestimmten Zeitpunkt erfassten Daten immer weniger darüber aus, ob die Kontrollen tatsächlich funktionierten.

Und dann sprengte das Ausmaß die Grenzen der manuellen Prozesse. Die Arbeit, Screenshots zu sammeln, Tabellen zu pflegen, Personen auf freigegebenen Laufwerken zu suchen und vierteljährliche E-Mail-Ketten zu führen, war bei fünfzig Personen noch erträglich, bei fünftausend jedoch absurd.

Jeder dieser Druckfaktoren hätte einzeln aufgefangen werden können. Zusammen jedoch erzwangen sie ein Umdenken.

Kurtes hatte inzwischen sein Studium abgeschlossen und sich selbstständig gemacht. Immer wieder baten ihn kleine Unternehmen um Hilfe mit ihren Systemen, die immer wieder auf Compliance-Probleme stießen. Also eignete er sich GRC erneut an, diesmal bei einem Dozenten, der sich wirklich dafür begeisterte, und beim zweiten Mal machte es Klick. Was ihn jedoch zurückhielt, war die Erkenntnis, die die Branche bald grundlegend verändern sollte: Compliance lässt sich nicht von den Systemen trennen, die sie regelt.

Die erste Antwort lautete Struktur und Standardisierung.

Der erste wirkliche Wandel bestand in der Standardisierung. Teams begannen, mit strukturierten Arbeitsabläufen, wiederverwendbaren Kontrollbibliotheken und einer gemeinsamen Sprache Ordnung in das Chaos zu bringen. Dadurch mussten sie die gleichen Compliance-Prozesse nicht mehr jedes Mal von Grund auf neu entwickeln. Eine Zeit lang funktionierte das gut. Die Auditvorbereitung wurde beschleunigt und die Beweiserhebung organisierter und weniger manuell.

Standardisierung hat jedoch ihre Grenzen. Sie kann zwar helfen, die zu prüfenden Aspekte zu strukturieren, aber sie kann nicht immer den tatsächlichen Zustand von Systemen erfassen. Jemand musste nach wie vor die Daten erheben und überprüfen, was tatsächlich vor sich ging.

Mit zunehmender Reife von GRC begannen die Teams, diese Lücke selbst zu schließen. Sie entwickelten Skripte, um Konfigurationen von Cloud-Anbietern abzurufen, Protokolle zu sammeln und Systeme zu verbinden, die nicht von Standard-Workflows abgedeckt wurden. Im Laufe der Zeit summierte sich dies. Die Compliance-Funktion begann allmählich, einer Softwarefunktion zu ähneln, auch wenn sie noch nicht so benannt war.

Das war die Arbeit, die Kurtes bereits erledigte. Python war seine Sprache. Er schrieb Collector, erstellte Templates und automatisierte die mühsamen Teile, nicht weil er einem Trend folgte, sondern weil die Arbeit es selbst erforderte.

Wie GRC Engineering entstand

Die eigentliche Entstehung von GRC Engineering ergab sich aus einer kritischen Betrachtung von DevOps. Denn DevOps hatte ein Jahrzehnt zuvor ein strukturell identisches Problem vor sich und es mit einer Reihe von Prinzipien gelöst: Infrastruktur als Code, Pipelines als zentrale Datenquelle, Qualität als Eigenschaft des Bereitstellungsprozesses und nicht als nachträglich hinzugefügte Phase.

GRC schlug denselben Weg ein. Richtlinien wurden als Code geschrieben und waren somit direkt in den Systemen implementiert, auf die sie Anwendung fanden. Nachweise wurden automatisch während des Systembetriebs generiert, anstatt später erfasst zu werden. Kontrollen wurden auch in den Bereitstellungsprozess integriert, um nicht konforme Änderungen vor deren Livegang zu verhindern.

Statt die Einhaltung der Vorschriften erst im Nachhinein zu überprüfen, wurde sie Teil des Prozesses, in dem Systeme entwickelt und ausgeliefert wurden.

Im alten Modell wurden die Beweise für die Einhaltung von Vorschriften erst im Nachhinein gesammelt. Im neuen Modell hingegen werden sie automatisch als Nebenprodukt der korrekten Systemfunktion generiert. Der Entwickler dieser neuen Ebene leistete Pionierarbeit, und der Markt brauchte einen Begriff dafür. So entstand der GRC-Ingenieur.

Was es tatsächlich ist: ein Mentalitätswandel

Von außen betrachtet wirkt GRC-Engineering wie eine reine Werkzeuggeschichte. Man sieht die Pipelines und die Richtlinien als Code und nimmt an, dass die gesamte Disziplin rein technisch und codegetrieben ist.

Aber es ist nicht so.

Die Veränderung lässt sich vereinfacht so zusammenfassen: Der Fokus verlagert sich von der manuellen Beweiserfassung hin zur Entwicklung von Systemen, die selbstständig Beweise generieren. Compliance ist kein separater Prozess mehr, der parallel zur Entwicklung läuft, sondern wird integraler Bestandteil der Systemkonzeption und des Systembetriebs.

Diese Denkweise steht jedem Anwender offen, ob mit oder ohne Programmierkenntnisse. Die richtige Einstellung steht an erster Stelle, die Werkzeuge folgen später. So entstand GRC-Engineering – durch die Arbeit von Praktikern wie Kurtes, die sich anpassten, noch bevor der Begriff überhaupt existierte. Heute ist diese Arbeitsweise nicht mehr nur eine Randerscheinung, sondern rückt in den Mittelpunkt. Und da sich die Technologie immer schneller weiterentwickelt, steht dieser Wandel jedem offen, der ihn mitgestalten möchte. Die Zukunft von GRC nimmt bereits Gestalt an.