Risikobasierte Genehmigung und Prüfnachweise in regulierten Unternehmen

Stellen Sie sich vor: Sie arbeiten für ein Fintech-Unternehmen, das Kundentransaktionen abwickelt. Oder vielleicht für ein Healthtech-Unternehmen, das Patientendaten speichert. Oder eine Versicherung, bei der jeder Schadensfall jederzeit prüfbar sein muss. Die Aufsichtsbehörde könnte morgen vor der Tür stehen und fragen: „Wer hat diese Änderung genehmigt? Was genau wurde geändert? Woher wissen Sie, dass es sicher war? Können Sie nachweisen, dass Ihr Team das korrekte Verfahren eingehalten hat, falls etwas schiefgelaufen ist?“

In einem kleinen Startup mag Vertrauen zwischen den Teammitgliedern ausreichen. In einem regulierten Unternehmen reicht Vertrauen nicht. Sie brauchen Nachweise. Jeder Schritt muss dokumentiert, unveränderlich gespeichert und jederzeit vorzeigbar sein.

Die erste Frage, die oft gestellt wird, lautet: „Wenn jede Änderung einen langen Genehmigungsprozess durchlaufen muss, wie können wir dann noch schnell ausliefern?“ Die Antwort ist nicht, die Genehmigung abzuschaffen. Die Antwort ist, die Genehmigung nur an den Stellen zu erzwingen, die tatsächlich ein Risiko darstellen. Das nennt man risikobasierte Genehmigung.

Warum nicht alle Änderungen gleich sind

Die Idee ist einfach. Nicht jede Änderung birgt das gleiche Risiko. Die Farbe eines Buttons auf einer Profilseite zu ändern, ist offensichtlich etwas anderes, als die Logik zur Berechnung von Darlehenszinsen zu ändern. Eine Abfrage zu bearbeiten, die Transaktionsdaten abruft, ist etwas anderes, als den Text auf der FAQ-Seite zu aktualisieren.

Eine Pipeline in einem regulierten Unternehmen muss den Unterschied erkennen können. Wenn ein Entwickler einen Pull-Request öffnet, kann die Änderung automatisch nach Staging fließen. Dort ist keine Genehmigung erforderlich. Aber wenn dieselbe Änderung in die Produktion gehen soll, muss die Pipeline anhalten und die Erlaubnis der richtigen Person einholen. Das kann ein Compliance-Beauftragter, ein designierter Tech Lead oder jemand aus dem Sicherheitsteam sein.

Die Pipeline sollte nicht einfach eine beliebige Genehmigung einholen. Sie muss wissen, wer genehmigt hat, wann und auf Basis welcher Informationen. Hat der Genehmiger die Testergebnisse gesehen? Hat er die Änderungsbeschreibung gelesen? War ein unterstützendes Dokument angehängt? All dies muss automatisch aufgezeichnet werden. Keine manuellen Screenshots. Keine in einem Ordner gespeicherten E-Mails. Das ist der automatisierte Prüfpfad.

Das folgende Flussdiagramm veranschaulicht den Entscheidungsweg vom Pull-Request bis zur Produktion und zeigt, wie die Risikostufe die Genehmigungspforte bestimmt und wie Prüfnachweise automatisch erfasst werden.

Hier ist ein praktisches Beispiel, wie Sie eine manuelle Genehmigungspforte in einem GitHub Actions-Workflow konfigurieren können, mit Umgebungsschutzregeln, die festlegen, wer genehmigen darf und welche Nachweise erfasst werden:

name: Deploy to Production

on:
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: make test
      - name: Security scan
        run: make security-scan
      - name: Deploy
        run: make deploy

Um die Genehmigung zu erzwingen, konfigurieren Sie die Umgebung production in Ihren Repository-Einstellungen mit erforderlichen Prüfern (z. B. compliance-officer, security-lead) und aktivieren Sie „Wait for approval“, bevor der Job ausgeführt wird. Das Audit-Log zeichnet automatisch auf, wer genehmigt hat, wann und welcher Commit bereitgestellt wurde.

Was einen guten Prüfpfad ausmacht

Ein guter Prüfpfad ist nicht nur ein Log, das besagt: „Alice hat um 15:42 Uhr auf Genehmigen geklickt.“ Ein guter Prüfpfad erfasst die gesamte Reise einer Änderung, vom ersten Commit bis zum Produktions-Deploy. Er zeichnet auf:

• Welche Commits enthalten waren
• Wer jeden Commit geschrieben hat
• Welche Tests gelaufen sind und ob sie bestanden wurden
• Wer den Code reviewed hat
• Wer den Deploy genehmigt hat
• Zu welcher Uhrzeit der Deploy stattfand
• Ob der Deploy erfolgreich war oder fehlschlug

All diese Daten müssen an einem Ort leben, den normale Entwickler nicht ändern können. Die Pipeline selbst sollte das einzige System sein, das in dieses Prüfpfad-Log schreibt. Wenn ein Entwickler das Log bearbeiten kann, ist der Prüfpfad wertlos.

Dies führt zum Konzept der Prüfnachweise. Prüfnachweise sind die Sammlung von Belegen, die Sie einer Aufsichtsbehörde zeigen können, um zu demonstrieren, dass Ihr Prozess die Regeln eingehalten hat. Diese Nachweise können ein automatisch generierter Bericht aus Ihrem Prüfpfad sein. Es können auch Artefakte wie Ergebnisse von Sicherheitsscans, Lasttestberichte oder digital signierte Änderungsdokumente sein. In einem gut geführten regulierten Unternehmen müssen Sie nicht hektisch Nachweise sammeln, wenn eine Prüfung angekündigt wird. Die Pipeline hat sie bereits automatisch zusammengestellt, jedes Mal, wenn eine Änderung vorgenommen wurde.

Balance zwischen Geschwindigkeit und Compliance

Der schwierigste Teil ist, die Balance zu halten. Zu lasch, und die Aufsichtsbehörde erteilt eine Verwarnung. Zu streng, und Ihr Team wird ausgebremst. Innovation stockt. Entwickler werden frustriert.

Die Lösung besteht darin, die Pipeline das Risiko anhand der Änderung unterscheiden zu lassen, nicht anhand der Person, die die Änderung vornimmt. Eine Änderung an der Produktionsdatenbank ist offensichtlich riskanter als eine Änderung am Frontend-Code. Eine Änderung, die das Zahlungsmodul betrifft, ist riskanter als eine Änderung an der FAQ-Seite. Die Pipeline sollte dies automatisch erkennen und anpassen, wie viele Genehmigungen erforderlich sind.

Wie kann eine Pipeline Risiken automatisch erkennen? Es gibt mehrere praktische Ansätze:

• Pfadbasierte Regeln: Änderungen unter src/payment/ erfordern zwei Genehmigungen. Änderungen unter src/docs/ erfordern keine.
• Dateityp-Regeln: Änderungen an SQL-Migrationsdateien erfordern die Freigabe durch einen Compliance-Beauftragten. Änderungen an CSS-Dateien nicht.
• Abhängigkeitsregeln: Wenn eine Änderung eine Bibliothek aktualisiert, die Verschlüsselung handhabt, markiert die Pipeline sie für eine Sicherheitsüberprüfung.
• Umfangserkennung: Wenn die Änderung sowohl Frontend- als auch Datenbankschichten betrifft, löst sie einen umfassenderen Genehmigungsprozess aus.

Diese Regeln sind nicht in Stein gemeißelt. Sie entwickeln sich weiter, während das Team lernt, was tatsächlich Probleme verursacht. Der Schlüssel ist, dass die Pipeline sie konsequent durchsetzt, ohne sich darauf zu verlassen, dass jemand daran denkt, eine Genehmigung einzuholen.

Eine praktische Checkliste für risikobasierte Genehmigung

Wenn Sie eine Pipeline für eine regulierte Umgebung einrichten, finden Sie hier eine kurze Checkliste:

• Risikostufen definieren: Listen Sie die Arten von Änderungen in Ihrem System auf und weisen Sie jeder eine Risikostufe zu. Niedrig, mittel, hoch. Fangen Sie einfach an.
• Genehmigungsregeln zuordnen: Legen Sie für jede Risikostufe fest, wer genehmigen muss und wie viele Genehmigende erforderlich sind.
• Risikoerkennung automatisieren: Konfigurieren Sie Ihre Pipeline, um basierend auf den geänderten Dateien, den betroffenen Modulen oder der Zielumgebung zu erkennen, welche Risikostufe zutrifft.
• Prüfdaten erfassen: Stellen Sie sicher, dass jeder Pipeline-Lauf aufzeichnet, wer was wann getan hat und was das Ergebnis war. Speichern Sie dies in einem Append-Only-System.
• Nachweise automatisch generieren: Erstellen Sie einen Bericht oder ein Dashboard, das Prüfdaten in ein Format bringt, das Aufsichtsbehörden prüfen können. Warten Sie nicht auf eine Prüfung, um dies zu erstellen.
• Prozess testen: Führen Sie eine Scheinprüfung durch. Bitten Sie jemanden, die Rolle der Aufsichtsbehörde zu spielen, und prüfen Sie, ob Ihre Nachweise Bestand haben. Beheben Sie Lücken vor einer echten Prüfung.

Das eigentliche Ziel

Am Ende des Tages ist ein reguliertes Unternehmen, das mit CI/CD erfolgreich ist, nicht dasjenige, das am schnellsten ausliefert. Es ist dasjenige, das nachweisen kann, dass jede Änderung den korrekten Prozess durchlaufen hat, ohne bei Änderungen mit geringem Risiko auf Geschwindigkeit zu verzichten. Das ist der Unterschied zwischen einer Organisation, die lediglich compliant ist, und einer, die compliant und dennoch wettbewerbsfähig ist.

Wenn Sie das nächste Mal eine Pipeline für eine regulierte Umgebung entwerfen, fragen Sie nicht zuerst, welches Tool Sie verwenden sollen. Fragen Sie zuerst: Welches Risiko birgt diese Änderung, und wie werden wir nachweisen, dass wir sie korrekt behandelt haben?