Sucht man nach Compliance-Automatisierungstools, erhält man eine Liste von Plattformen, die eine Aufgabe erfüllen: Sie verbinden sich mit deinem Stack, sammeln Beweise, dass deine Kontrollen funktionieren, und bereiten dich auf ein SOC 2- oder ISO 27001-Audit vor. Diese Ebene ist real und nützlich. Für ein Engineering-Team gibt es jedoch eine zweite Ebene, die in solchen Listen meist fehlt: der Pull Request, in dem eine Kontrolle tatsächlich umgesetzt wird, eine Änderung nach der anderen, Monate bevor ein Audit sie prüft.
Dies ist eine neutrale Übersicht beider Ebenen. Jedes Tool wird durch seinen eigenen, klar formulierten Zweck beschrieben, ohne Bewertung oder Kritik. Es geht nicht darum, welches Tool gewinnt, sondern darum, dass die beiden Ebenen unterschiedliche Fragen beantworten und die meisten Teams am Ende eines aus jeder Ebene benötigen.
Die Compliance-Programm-Plattformen
Dies sind die Tools, die die meisten unter Compliance-Automatisierung verstehen. Sie verbinden sich mit deiner Cloud, deinem Identity Provider und anderen Systemen, automatisieren das Sammeln von Beweisen, dass Kontrollen funktionieren, überwachen diese Beweise kontinuierlich und helfen dir, dich auf ein Audit gegen Frameworks wie SOC 2, ISO 27001 und die DSGVO vorzubereiten. Sie arbeiten auf der Ebene deines Compliance-Programms: Richtlinien, Kontrollen, Beweise und Audit-Bereitschaft für die gesamte Organisation.
Vanta, Drata und Scytale sind weit verbreitete SaaS-Plattformen in diesem Bereich, die jeweils das Sammeln von Beweisen und die kontinuierliche Überwachung für gängige Frameworks automatisieren. Probo ist eine Open-Source-, selbsthostbare Option, die denselben GRC-Lebenszyklus (Kontrollen, Risiken, Anbieter, Beweise) abdeckt und CLI-, GraphQL- und MCP-APIs bereitstellt, sodass die Arbeit über Code oder einen Agenten gesteuert werden kann. ControlMap, Teil von ScalePad, automatisiert das Sammeln von Beweisen über eine breite Framework-Bibliothek, die gängige Sicherheits- und Datenschutzstandards abdeckt.
Wenn dein Ziel darin besteht, ein Compliance-Programm aufzubauen und auditbereit zu werden, ist dies die Kategorie, die du bewerten solltest. Welches Tool passt, hängt von deinen Frameworks, deinem Stack und davon ab, ob du SaaS oder selbstgehostet bevorzugst, und diese Entscheidung triffst du anhand der Dokumentation jedes Anbieters.
Die Pull-Request-Ebene
Programm-Plattformen verwalten Beweise, Kontrollen und Audit-Bereitschaft über deine Systeme hinweg. Engineering-Teams haben jedoch einen zweiten Ort, an dem Compliance entschieden wird: den Pull Request, in dem eine Änderung einen Zugriffspfad erweitern, ein Audit-Log kürzen oder einen neuen Speicher für personenbezogene Daten hinzufügen kann. Das sind kontrollrelevante Designentscheidungen, und ein Pull Request ist der Ort, an dem sie diskutiert werden können, bevor sie gemergt werden.
heygrc ist diese Pull-Request-Ebene. Es prüft jede Änderung gegen die Frameworks, die dein Unternehmen ausgewählt hat, und verweist auf die spezifische Kontrolle, die sie betrifft, direkt im Diff, als Review-Kommentar sowie als neutralen Checks-Status. Es ist keine Programm-Plattform: Es sammelt keine Beweise und verwaltet kein Audit. Es fügt eine frameworkbewusste Prüfung einer Änderung in GitHub hinzu, bevor sie gemergt wird.
Die beiden Ebenen ergänzen sich also, statt zu konkurrieren. Die Programm-Plattform verwaltet Beweise und Audit-Bereitschaft; heygrc fügt eine frameworkbewusste Prüfungskontext in GitHub hinzu, bevor Änderungen gemergt werden. Ein Engineering-Team, das eine Zertifizierung anstrebt, benötigt oft beides: eines für das Programm und eines für die Compliance-Prüfung auf Pull-Request-Ebene.