Wie man einen Compliance-zentrierten Entwicklungsprozess aufbaut

Bei der Einführung eines neuen Systems wird die Compliance oft erst dann thematisiert, wenn die erste Version fertiggestellt ist und rechtliche oder informationssicherheitsrelevante Prüfungen Mängel aufdecken. Dann folgen späte Anpassungen, erneute Tests, unklare Verantwortlichkeiten und Verzögerungen beim Start. Die Frage ist daher nicht nur, wie man einen compliance-orientierten Entwicklungsprozess aufbaut, sondern auch, wie man Compliance zu einem überprüfbaren Teil des täglichen Betriebs macht, ohne die Entwicklung unnötig zu verlangsamen.

Compliance ist kein separates Dokumentenbündel. In einem Lagersystem kann es bedeuten, dass Bestandsbewegungen nachvollziehbar sind und nicht nachträglich spurlos geändert werden können. In einem E-Commerce-Prozess bedeutet es, dass die Verarbeitung personenbezogener Daten zweckgebunden und protokolliert ist. In der Produktion bedeutet es, dass eine Qualitätsabweichung, Genehmigung oder Rezepturänderung eindeutig einer verantwortlichen Rolle zugeordnet werden kann. Der gemeinsame Punkt ist in jedem Fall die Kontrollierbarkeit.

Compliance ist nicht das letzte Tor der Entwicklung

In vielen Unternehmen beginnt der Entwicklungsprozess mit einer einfachen Formel: Das Geschäft formuliert ein Bedürfnis, das Entwicklungsteam erstellt die Funktion, und jemand überprüft, ob sie nutzbar ist. Dies funktioniert akzeptabel, wenn der Prozess mit wenigen Systemen verbunden ist, wenig Daten verarbeitet und ein Fehler keine schwerwiegenden betrieblichen oder vertraglichen Konsequenzen hat.

In wachsenden Unternehmen bleibt eine Änderung jedoch selten innerhalb der Grenzen einer einzigen Anwendung. Ein neuer Bestellstatus kann Auswirkungen auf den Webshop, das ERP, die Rechnungsstellung, die Kurierintegration und die Managementberichte haben. Wenn es keine klaren Regeln gibt, wer Daten ändern darf, welches System der Datenverantwortlicheist, was als genehmigte Änderung gilt und wie eine fehlerhafte Veröffentlichung zurückgesetzt werden kann, dann ist das Compliance-Risiko tatsächlich ein Betriebsrisiko.

Das Ziel ist also nicht, für jede Entwicklungsaufgabe unverhältnismäßige Bürokratie zu schaffen. Das Ziel ist, dass Entscheidungen, kritische Kontrollen und Prüfungsnachweise dort im Prozess vorhanden sind, wo sie wirklich benötigt werden.

Wie baut man einen compliance-orientierten Entwicklungsprozess ausgehend vom Geschäftsprozess auf?

Der richtige Ausgangspunkt ist nicht die Richtlinie und auch nicht die Entwickler-Toolchain. Zuerst muss man verstehen, welches Geschäftereignis das System behandelt, wer Entscheidungen trifft, auf welcher Grundlage und was passiert, wenn ein Schritt fehlerhaft ist oder ausbleibt.

Nehmen wir ein einfaches Beispiel: Ein Kundenservicemitarbeiter ändert die Lieferadresse einer Bestellung. Auf den ersten Blick scheint dies eine kleine Funktion zu sein. Die betrieblichen Fragen sind jedoch wichtig: Bis wann ist die Änderung erlaubt, ist eine Begründung erforderlich, wer genehmigt bei Bestellungen mit hohem Wert, wird die Änderung an den Spediteur weitergegeben und ist später sichtbar, wer sie vorgenommen hat? Wenn es darauf keine Antworten gibt, kann der Entwickler höchstens ein Datenfeld und eine Speichertaste erstellen. Einen kontrollierten Prozess nicht.

Bei der Erkundung lohnt es sich, bei jeder wesentlichen Änderung drei Dinge zu klären: Welche Verpflichtung oder interne Regel ist damit verbunden, welches Fehlverhalten oder Missbrauch kann durch die Kontrolle verhindert werden und was wird der überprüfbare Nachweis dafür sein, dass die Kontrolle funktioniert hat. Dies kann ein Berechtigungsprotokoll, ein Genehmigungsrekord, ein versioniertes Dokument, ein Testergebnis oder ein Wiederherstellungsprotokoll sein. Nicht in jedem Fall ist alles erforderlich, aber die Entscheidung muss bewusst getroffen werden.

Die Anforderungen müssen testbar sein

Sätze wie „sicher sein“ oder „den Vorschriften entsprechen“ sind nicht als Entwicklungsanforderung geeignet. Sie geben nicht an, was gebaut werden soll, wer es überprüft und wann die Anforderung als erfüllt gilt.

Eine brauchbare Anforderung ist konkret. Zum Beispiel: Der Benutzer kann nur die Warenbewegungen seines eigenen Standorts sehen; die Menge einer genehmigten Bestellung kann nicht ohne neue Genehmigung geändert werden; die Erstellung des Finanzexports wird protokolliert; die Änderung von systemkritischen Einstellungen erfordert zwei separate Rollen. Aus diesen können Planungsentscheidungen, Testfälle und spätere Prüfungen erstellt werden.

Es ist wichtig, obligatorische Kontrollen von Komfortanforderungen zu trennen. Wenn eine interne Genehmigung von einem einzigen Vertriebsadministrator abhängt, der im Urlaub nicht ersetzt werden kann, kann das System zwar einer dokumentierten Regel entsprechen, aber das Geschäft kann zum Stillstand kommen. Gute Compliance ist nicht nur streng, sondern auch umsetzbar.

Entwicklungsdisziplin sollte risikobasiert unterschiedlich sein

Es ist nicht gerechtfertigt, dasselbe Prüfungsniveau für die Änderung des Layouts eines internen Berichts und die Überarbeitung einer Rechnungsdatenübertragung anzuwenden. Ein zu einheitlicher Prozess verlangsamt kleinere Korrekturen, sodass die Mitarbeiter mit der Zeit Umgehungswege suchen. Ein zu lockerer Prozess lässt jedoch gerade bei kritischen Änderungen eine Lücke offen.

Es ist nützlich, Änderungen nach mindestens drei Gesichtspunkten zu bewerten: Berührt es personenbezogene, finanzielle oder geschäftlich sensible Daten; ändert es Berechtigungen, Genehmigungen oder Protokollierungen; und kann es zu Betriebsstörungen in mehreren verbundenen Systemen führen. Für eine Änderung mit geringem Risiko kann die übliche Entwicklerprüfung und geschäftliche Abnahme ausreichen. Bei höherem Risiko kann eine separate fachliche Genehmigung, ein Integrationstest, ein Wiederherstellungsplan und eine dokumentierte Freigabeentscheidungerforderlich sein.

Dies ist keine Bürokratie, sondern Kapazitätsschutz. Die Aufmerksamkeit des Teams konzentriert sich dort, wo eine schlechte Entscheidung später zu Datenkorrekturen, Kundenbeschwerden, fehlerhaften Rechnungen oder Produktionsunterbrechungen führen kann.

Bei der Planung müssen Kontrollen zu Systemfunktionen werden

Die Erfüllung von Compliance-Anforderungen ergibt sich nicht daraus, dass sie in einem Projektordner stehen. Kritische Regeln müssen in den Prozess integriert werden. Wenn ein Schritt eine Genehmigung erfordert, muss das System den Status, die genehmigende Rolle, den Zeitstempel und Ausnahmefälle verwalten. Wenn Nachverfolgbarkeit erforderlich ist, muss das Protokoll auch festhalten, was sich geändert hat, nicht nur, dass jemand eingeloggt ist.

Die Berechtigungsverwaltung ist ein besonders häufiger Schwachpunkt. In vielen Systemen erhalten Benutzer im Laufe der Zeit „vorübergehend“ erweiterte Zugriffsrechte, die dann dauerhaft bestehen bleiben. Bei der Planung sollte man in Rollen statt in Personen denken und die Initiierung, Kontrolle und Genehmigung dort trennen, wo dies geschäftlich relevant ist. In kleinen Unternehmen ist eine vollständige Trennung der Aufgaben nicht immer möglich. In solchen Fällen kann eine kompensatorische Kontrolle erforderlich sein, z. B. eine nachträgliche Überprüfung durch die Leitung oder eine regelmäßige Protokollüberprüfung.

Die Ausnahmebehandlung ist mindestens ebenso wichtig. In der realen Praxis gibt es fehlerhafte Importe, dringende Bestellungen, ausgefallene externe Dienste oder fälschlicherweise abgeschlossene Arbeitsaufträge. Ein System unterstützt die Compliance, wenn die Ausnahme keinen versteckten Umgehungsweg darstellt, sondern einen festgelegten, protokollierten und nachträglich überprüfbaren Prozess.

Tests müssen auch den Nachweis überprüfen

Der Funktionstest prüft, ob das System das tut, was es soll. Bei compliance-orientierter Entwicklung muss auch überprüft werden, ob es verhindert, was nicht erlaubt ist, und ob es das aufzeichnet, was später nachgewiesen werden muss.

Ein Test des Genehmigungsprozesses darf daher nicht damit enden, dass die Genehmigungstaste funktioniert. Es muss geprüft werden, ob ein unberechtigter Benutzer den Schritt einleiten kann, ob der Inhalt nach einer Genehmigung geändert werden kann, ob das Protokoll korrekt angezeigt wird und in welchem Zustand die Transaktion bei fehlerhafter Integration verbleibt. Negative Tests sagen oft mehr über die Qualität der Kontrollen aus als die gewohnten, erfolgreichen Prozesse.

Die geschäftliche Abnahme sollte nicht als formale Unterschrift behandelt werden. Die Aufgabe des Prozessverantwortlichen ist es nicht, allgemein zu erklären: „Es ist in Ordnung“. Es muss bestätigt werden, dass das System in den tatsächlichen Betriebsbedingungen mit den Ausnahmen die festgelegten Regeln unterstützt. Dazu müssen die Testdaten auch glaubwürdige Szenarien widerspiegeln.

Freigabe und Betrieb sind Teil desselben Prozesses

Die Entwicklung endet nicht mit der Live-Bereitstellung. Die beste Planungs- und Testarbeit ist wenig wert, wenn nicht klar ist, wer über die Freigabe entscheidet, wie die ersten Betriebsverarbeitungen überprüft werden und was im Fehlerfall passiert.

Bei jeder wesentlichen Freigabe sollte ein Verantwortlicher für die geschäftliche Annahme der Änderung, die technische Durchführung und die nachträgliche Überprüfung benannt werden. Der Wiederherstellungsplan darf kein theoretisches Dokument sein. Es muss bekannt sein, welche Datenbewegungen während der Freigabe stattfinden können, was automatisch wiederhergestellt werden kann und ab welchem Punkt auch eine geschäftliche Datenkorrektur erforderlich ist.

Zu den Betriebskontrollen kann die regelmäßige Überprüfung der Berechtigungen, die Behandlung fehlerhafter oder wiederholter Integrationsnachrichten, die Protokollaufbewahrung und die nachträgliche Überprüfung außergewöhnlicher Änderungen gehören. Die Häufigkeit hängt von der Bedeutung des Systems ab. Ein System, das die Produktion oder Lieferung direkt unterstützt, erfordert eine andere Aufmerksamkeit als ein selten genutztes internes Register.

Nachhaltige Compliance zeigt sich nicht daran, dass es viele Regeln gibt. Sondern daran, dass ein neuer Mitarbeiter seine Rolle versteht, ein Vorgesetzter die kritischen Entscheidungen nachvollziehen kann und eine fehlerhafte Änderung das Team nicht zu manueller Datensuche zwingt. Wenn bei der nächsten Entwicklungsanforderung zuerst der betroffene Prozess, die Verantwortlichkeiten und die überprüfbaren Kontrollen geklärt werden, wird Compliance nicht zur Bremse, sondern zur Grundlage eines berechenbaren Betriebs.