Compliance nachweisen: Release Register und Sicherheitstests pro Release

Die Mail, auf die niemand vorbereitet ist

Stell dir eine Firma mit zwölf Leuten in Linz vor, die Terminsoftware an Zahnarztpraxen verkauft. Eine Mail kommt an, vom Einkauf eines großen Kunden, vom Versicherer zur Verlängerung oder von einem Wirtschaftsprüfer, den eine Bank zur Buchhaltungssoftware geschickt hat. Im Anhang ein Fragebogen. Frage vierzehn lautet ungefähr: Beschreibe deinen sicheren Entwicklungsprozess und lege Nachweise über Sicherheitstests der aktuell produktiven Version vor.

Die Inhaberin nimmt Sicherheit wirklich ernst. Das Hosting ist gut, der Entwickler weiß, was SQL Injection ist. Und trotzdem gibt es nichts, was sie anhängen könnte. Nicht weil nichts getan wurde, sondern weil nichts so aufgeschrieben wurde, dass jemand anderes es prüfen kann.

Um diese Lücke geht es hier. Nicht in erster Linie ums Recht. Über den Cyber Resilience Act, NIS2 und die KI Verordnung habe ich eigene Artikel geschrieben, und die sagen dir, was verlangt ist. Dieser hier handelt von der unspektakulären Mechanik, mit der eine kleine Firma ruhig und mit einem PDF in der Hand sagen kann: Das haben wir released, das hat es getestet, hier ist der Bericht, und das ist die Version, die gerade läuft.

Die Linzer Firma und alle anderen Unternehmen in den Beispielen sind erfunden. Recht und Normen stehen in den Fußnoten. Wo ich beschreibe, was ich für Kunden mache, beschreibe ich nur, was heute auf meiner Website veröffentlicht ist.

Was Nachweis eigentlich heißt

Der größte Teil der Verwirrung steckt in einem Wort, deshalb lohnt sich eine Definition.

"Wir nehmen Sicherheit ernst" ist eine Behauptung. "Wir folgen Best Practices" ist eine Behauptung. Ein Richtliniendokument, in dem steht, dass Releases vor dem Deployment getestet werden, ist auch eine Behauptung, und zwar eine schwache, denn eine Richtlinie kann jeder schreiben.

Ein Nachweis ist eine Aufzeichnung, die ein Dritter prüfen kann, ohne dir zu vertrauen. Sie hat ein Datum. Sie nennt eine bestimmte Version eines bestimmten Systems. Sie nennt, wer etwas getan hat, und verweist auf das Ergebnis. Und sie liegt an einem Ort, an dem sie nicht nachträglich still verändert werden konnte.

Das klingt pingelig, bis du auf der anderen Seite des Tisches sitzt. Ein Prüfer wird nicht dafür bezahlt, dir zu glauben. Der Schadenregulierer eines Versicherers sucht, sobald etwas schiefgegangen ist und Geld im Spiel ist, nach der Lücke zwischen dem, was du bei der Verlängerung gesagt hast, und dem, was du zeigen kannst. Ein Einkäufer im Konzern hat eine Checkliste und eine Rechtsabteilung, und "vertrau uns" hakt kein Kästchen ab.

Alles Weitere baut deshalb auf einer Frage auf. Kannst du für jedes Produktivsystem, zu jedem Zeitpunkt, eine Aufzeichnung vorlegen, welche Version läuft, was sich darin geändert hat, wer sie wann getestet hat und wo der Bericht liegt? Wenn ja, werden die meisten Fragebögen zu Kopieren und Einfügen. Wenn nein, wird jeder Fragebogen zur Hektik.

Was das Recht von dir zeigen will

Die Regeln unterscheiden sich im Anwendungsbereich, aber sie teilen ein Verb: nachweisen.

DSGVO. Artikel 5 Absatz 2 macht den Verantwortlichen für die Einhaltung der Grundsätze verantwortlich und verlangt, dass er sie nachweisen kann. Artikel 32 verlangt Sicherheit, die dem Risiko angemessen ist, und nennt unter den Maßnahmen "ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen".¹ Ein Test ohne Aufzeichnung weist nichts nach.

NIS2. Artikel 21 verpflichtet wesentliche und wichtige Einrichtungen zu Risikomanagementmaßnahmen, darunter Sicherheit der Lieferkette, Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen "einschließlich Management und Offenlegung von Schwachstellen" und Konzepte, um die Wirksamkeit der Maßnahmen zu bewerten. Artikel 23 setzt die Uhr für erhebliche Sicherheitsvorfälle: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen eines Monats.² Fällt einer deiner Kunden darunter, ist die Lieferkettenklausel der Grund, warum sein Brief auf deinem Tisch landet.

NIS2 in Österreich. Das Netz und Informationssystemsicherheitsgesetz 2026 wurde am 23. Dezember 2025 kundgemacht und gilt seit 1. Oktober 2026, mit dem Bundesamt für Cybersicherheit als Behörde.³ Die Maßnahmen stehen in § 32 NISG 2026, die Berichtspflichten mit denselben Fristen in § 34, und § 33 verlangt ausdrücklich den Nachweis, dass die Maßnahmen wirken.⁴⁵⁶

NIS2 in den Nachbarländern. In Deutschland wurde das NIS2 Umsetzungs und Cybersicherheitsstärkungsgesetz am 5. Dezember 2025 verkündet und hat das BSI Gesetz neu gefasst.⁷ Irland hat die Richtlinie noch nicht umgesetzt: Die Kommission hat Irland im Juli 2026 vor den Gerichtshof gebracht, und die Regierung erklärte im Oktober, der National Cyber Security Bill werde noch ausgearbeitet. Stand meiner Prüfung am 11. November 2026 steht kein solcher Entwurf in der Gesetzesliste des irischen Parlaments.⁸⁹ Hast du Kunden im Vereinigten Königreich, gilt dort die UK GDPR mit denselben Artikeln, und die Aufsicht heißt seit 30. September 2026 Information Commission statt ICO.¹⁰

Der Cyber Resilience Act. Bringst du Softwareprodukte auf den EU Markt, gilt die Pflicht, aktiv ausgenutzte Schwachstellen und schwere Vorfälle zu melden, ab 11. September 2026, der Rest der Verordnung ab 11. Dezember 2027.¹¹ Ihre grundlegenden Anforderungen erwarten Sicherheitsupdates und eine Aufzeichnung der behandelten Schwachstellen über die Lebensdauer des Produkts, also ein Release Register unter anderem Namen.

PCI DSS. Nimmst du Kartenzahlungen an, gilt der Payment Card Industry Data Security Standard derzeit in Version 4.0.1, veröffentlicht im Juni 2024, und die bis dahin zukunftsdatierten Anforderungen sind seit 31. März 2025 verpflichtend.¹² Unter anderem verlangt er, dass Änderungen an der Produktion dokumentierten Verfahren folgen, kritische Sicherheitspatches binnen eines Monats nach Erscheinen eingespielt werden, Penetrationstests mindestens alle zwölf Monate und nach wesentlichen Änderungen stattfinden und Audit Logs mindestens zwölf Monate aufbewahrt werden, die letzten drei sofort verfügbar.¹³

ISO/IEC 27001:2022. Die zertifizierbare Norm für Informationssicherheitsmanagement. Ihre Anhang A Kontrollen umfassen einen sicheren Entwicklungslebenszyklus (8.25), Sicherheitstests in Entwicklung und Abnahme (8.29), Änderungsmanagement (8.32), Protokollierung (8.15) und das Management technischer Schwachstellen (8.8).¹⁴ Alles Folgende passt auf diese Kontrollen, was hilft, falls Zertifizierung je ein Thema wird.

Barrierefreiheit. Der European Accessibility Act gilt seit 28. Juni 2025 für Dienstleistungen im elektronischen Geschäftsverkehr an Verbraucher, in Österreich umgesetzt durch das Barrierefreiheitsgesetz.¹⁵¹⁶ Auch Barrierefreiheit ist eine Eigenschaft des Release: Ein Checkout, der im März bestanden hat, kann im April durchfallen. Die Details stehen in meinem Artikel zu den Anforderungen an Barrierefreiheit.

Sechs verschiedene Texte. Keiner verlangt Perfektion. Alle fragen, ob du zeigen kannst, was du getan hast.

Die eine Gewohnheit, an der alles hängt

Jedes Produktions Release bekommt eine Versionsnummer und Release Notes. Das ist die Gewohnheit.

Jedes Release, nicht nur die großen. Auch das Deployment am Dienstagnachmittag, das einen Tippfehler behebt, bekommt eine Version. Denn wenn nächsten Monat jemand fragt, was sich zwischen der Version, die der Penetrationstester gesehen hat, und der Version, die jetzt läuft, geändert hat, muss die Antwort eine Liste sein, kein Achselzucken.

Das Schema ist weniger wichtig als die Disziplin, aber wähl eins und schreib es auf. Für Produkte mit festen Erscheinungsterminen passt Semantic Versioning, das bekannte Muster 2.4.1. Für Anwendungen, die mehrmals pro Woche ausgerollt werden, sind Kalenderversionen oft klarer: Jahr, Monat und ein Zähler, also ist 2026.11.3 das dritte Release im November 2026. Du siehst auf einen Blick, wie alt die laufende Version ist, und genau das will ein Versicherer wissen.

Release Notes sind kein Marketing. Es sind drei kurze Listen, was hinzukam, was sich änderte, was entfernt wurde, dazu ein Zeitstempel und wer das Release freigegeben hat. So dokumentiere ich Releases für Kunden: Produktions Releases sind versioniert, mit Zeitstempel und in diesen drei Listen festgehalten, damit die Frage "was genau ging wann live" immer eine Antwort hat.¹⁷

Alles andere in diesem Artikel hängt an diesem Register. Sicherheitstests verweisen auf eine Version. Freigaben kritischer Pfade verweisen auf eine Version. Abfragen im Audit Log sind durch Versionen begrenzt. Nimm das Register weg, und der Rest ist ein Stapel Dokumente ohne Rückgrat.

Das Register ist das Rückgrat. Jeder Schritt danach verweist auf eine Versionsnummer.

Sicherheitstests sind eine Eigenschaft der Version, keine Richtlinie

Das ist der Perspektivwechsel, der den Fragebogen einfach macht.

Die meisten kleinen Firmen behandeln Sicherheitstests, wenn überhaupt, als Ereignis. "Wir hatten 2024 einen Pentest. Irgendwo liegt ein PDF." Das Problem: Das 2024 getestete System gibt es nicht mehr. Es wurde seitdem vierzigmal ausgerollt. Der Bericht beweist, dass ein System, das nicht mehr läuft, einmal einigermaßen sicher war.

Das bessere Modell erfasst Sicherheitstests gegen eine Version. Die Aufzeichnung sagt: Version 2026.11.3 des Kundenportals, geprüft an diesem Tag, von dieser Person oder diesem Werkzeug, hier ist der Bericht, bestanden oder nicht. Nicht jedes Release braucht dieselbe Tiefe, und das ist in Ordnung, solange festgehalten ist, was für welche Version getan wurde.

Was die Prüfung enthält, hängt von der Änderung und vom Stack ab. Für eine Rails Anwendung sieht eine vernünftige Grundlage so aus.

Statische Analyse bei jedem Build. Brakeman durchsucht Rails Code nach Sicherheitsproblemen wie SQL aus zusammengesetzten Strings, nicht maskierter Ausgabe, Mass Assignment und Weiterleitungen auf vom Nutzer gelieferte Adressen.¹⁸ Es ist kostenlos, dauert eine Minute, und der Build kann bei neuen Warnungen fehlschlagen.

Ein Abhängigkeitsaudit bei jedem Build. Das Gem bundler audit prüft deine Bibliotheken gegen eine Datenbank bekannter Schwachstellen, dazu das Gegenstück für die JavaScript Seite.¹⁹ Das ist die günstigste Antwort auf die Patchanforderung aus PCI DSS und die Klausel zum Schwachstellenmanagement aus NIS2, weil es dir am selben Tag sagt, wenn eine deiner Bibliotheken zum Problem wird.

Scans der laufenden Anwendung. Automatisierte Scans gegen die üblichen Klassen von Injection und Cross Site Scripting, gerichtet auf das ausgerollte System und nicht nur auf den Code, weil sie die tausend Varianten probieren, die ein Mensch auslässt.

Penetrationstests. Ein Mensch mit einem Auftrag, der versucht hineinzukommen. Bei einem großen Release oder einem neuen System die volle Übung. Bei einer Routineänderung ein gezielter Blick auf das, was sich geändert hat. Auf den Systemen, die ich baue, bekommen große Produktions Releases zusätzlich zu den automatischen Suiten Web Application Security Tests, fundiert durch eine formale Ausbildung in Offensive Security.¹⁷

Last und Resilienzübungen, wo es zählt. Kostet Ausfall Geld, und NIS2 interessiert sich ausdrücklich für Verfügbarkeit, dann hat jemand das System belastet, bis es umfiel, und aufgeschrieben, wo das war.

Leg die Berichte ins Dokumentationsrepository des Produkts, in Git, benannt nach der Version, auf die sie sich beziehen. Ein Git Repository ist ein Hauptbuch: Jede Änderung hat Zeitstempel und Urheber, und die Geschichte umzuschreiben ist schwer und sichtbar. Fragt ein Prüfer, woher er weiß, dass ein Bericht nicht letzte Woche geschrieben wurde, antwortet die Commit Historie.

Eine Ampel pro System

Ein Hilfsmittel macht aus all dem etwas, das eine Inhaberin lesen kann, ohne einen einzigen Bericht zu öffnen: eine Ampel pro Firma oder pro System.

Rot heißt, es wurde noch nie eine Sicherheitsprüfung erfasst. Gelb heißt, die Version, die in Produktion läuft, ist noch nicht geprüft, meist weil gerade etwas released wurde und die Prüfung noch aussteht. Grün heißt, für die aktuelle Version jeder Produktivanwendung liegt eine bestandene Prüfung vor.

Das ist die ganze Regel. Eine schöne Richtlinie macht sie nicht grün, ein gutes Gefühl auch nicht. Sie springt auf Gelb, sobald ein Release rausgeht, und zurück auf Grün, wenn die Prüfung nachgezogen ist. Drei Wochen Gelb sind ein Gespräch. Rot ist ein Notfall. Grün ist der Screenshot, den du an den Fragebogen hängst.

Sie verändert auch das Verhalten. Wenn jedes Release die Ampel auf Gelb setzt, bis es geprüft ist, bündeln Leute kleine Änderungen und testen ordentlich. Genau diese Gewohnheit wollen die Regeln des Cyber Resilience Act zum Umgang mit Schwachstellen erzeugen.

Wer fragt, und was eigentlich gewollt ist

Die Fragebögen kommen aus sechs Richtungen, und sie sind Varianten derselben wenigen Fragen.

Der Prüfer. Meist ein Wirtschaftsprüfer oder ein IT Prüfer in seinem Auftrag, der Sicherheit braucht, dass ein System, das Finanzzahlen erzeugt, tut, was es behauptet, und nicht manipuliert wurde. Er fragt, welche Version läuft, welche Kontrollen es über Änderungen gibt, wer ändern darf und ob jede Änderung aufgezeichnet ist. Ein Release Register mit erfassten Testläufen ist fast die ganze Antwort. Die Logik selbst decken die verifizierten kritischen Pfade weiter unten ab.

Der Versicherer. Fragebögen zur Cyberversicherung fragen typischerweise nach Mehrfaktorauthentifizierung, Patches innerhalb einer festgelegten Frist, auf Wiederherstellung getesteten Backups, Protokollierung von Zugriffen und Änderungen, einem aktuellen Penetrationstest und einem Notfallplan. Bei der Verlängerung will er Häkchen. Im Schadenfall will er Beweise, dass die Häkchen am betreffenden Tag stimmten. Datierte Prüfaufzeichnungen und ein exportierbares Audit Log machen die Häkchen belastbar.

Der NIS2 Lieferantenbrief. Ein betroffener Kunde muss nach Artikel 21 das Risiko in seiner Lieferkette steuern, also fragt er, ob du Schwachstellen behandelst, wie schnell du patchst, ob du Releases testest und ob du ihn über Vorfälle schnell genug informieren kannst, damit seine eigene 24 Stunden Frist hält.² Register und Prüfungen pro Version sind der Nachweis. Die Meldung an den Kunden ist ein Absatz in deinem Notfallplan.

Der Konzerneinkauf. Das längste Formular, oft eine Tabelle mit zweihundert Zeilen, von denen die meisten nicht zu einer Firma deiner Größe passen. Der Rest fragt nach sicherer Entwicklung, Zugriffskontrolle, Verschlüsselung, Protokollierung, Betriebskontinuität und Unterauftragsverarbeitern. Hier schlägt ein "Nein, aber" mit Nachweis ein "Ja" ohne. "Es gibt kein eigenes Sicherheitsteam, aber jedes Release ist erfasst, hier ist das Register und hier sind die letzten drei Berichte" kommt durch.

Die Datenschutzaufsicht. Seltener, aber nach einer Beschwerde oder einer Datenpanne fragt die Datenschutzbehörde, welche technischen und organisatorischen Maßnahmen du nach Artikel 32 hattest und ob du sie nachweisen kannst.¹ Gleiches Register, gleiche Berichte.

Die Bank oder der Zahlungsdienstleister. Kreditgeber und Zahlungsanbieter stellen immer öfter eine Kurzfassung der Versicherungsfragen, bevor sie Konditionen gewähren, und wer Karten annimmt, trifft auf die PCI DSS Fragen von oben.¹³

Sechs Zielgruppen, ein Register, ein Satz Prüfaufzeichnungen, ein Audit Log, ein Ort für unterschriebene Dokumente. Am Ende fragen alle dasselbe: Kannst du es mir zeigen, oder muss ich dir aufs Wort glauben?

Verifizierte kritische Pfade, wenn die Logik selbst das Risiko ist

Manche Systeme enthalten Logik, die, wenn sie falsch ist, kein Bug ist, sondern eine Haftung. Die Rechnung, die Kosten zwischen den Mitgliedern einer Genossenschaft aufteilt. Die Regel, welche Rechtsdokumente ein Kunde für welches Produkt akzeptiert. Eine Tarifberechnung. Eine Provisionsaufteilung.

Hier reicht es nicht zu testen, ob der Code tut, was der Entwickler meinte. Die Frage ist, ob das, was der Entwickler meinte, das ist, was der Kunde und dessen Prüfer für die Regel halten.

Ein verifizierter kritischer Pfad beantwortet das. Die Logik wird in Alltagssprache aufgeschrieben, für den Kunden statt für Entwickler, neben den ausführbaren Tests, die beweisen, dass sich das System so verhält. Der Kunde liest es und gibt es frei, und in diesem Moment wird es eingefroren. Jede spätere Änderung an der Logik öffnet die Freigabe wieder, damit die Aufzeichnung nie von dem abweicht, was das System tatsächlich tut. So behandle ich kritische Geschäftslogik für Kunden: in Alltagssprache aufgeschrieben, vom Kunden freigegeben, in diesem Zustand eingefroren, als PDF auf Deutsch und Englisch für den Prüfer exportierbar, und Änderungen öffnen die Freigabe wieder.¹⁷

Der Prüfer bekommt nicht "der Entwickler sagt, es funktioniert". Er bekommt die Regel in Worten, die Freigabe dieser Regel durch den Kunden an einem Datum, die Tests, die prüfen, dass das System ihr folgt, und den Nachweis, dass sich seitdem nichts geändert hat. ISO 27001 nennt die Ideen dahinter Sicherheitstests in der Abnahme und Änderungsmanagement.¹⁴

Die Fassung in Alltagssprache hat einen Nebeneffekt, den man haben will. Sie erzwingt ein Gespräch darüber, was die Regel wirklich ist, und in diesem Gespräch tauchen fehlende Fälle auf, bevor sie Code sind.

Releases hinter Tests, und warum die Tests für den Kunden sind

Das ganze Plädoyer für testgetriebene und verhaltensgetriebene Entwicklung wiederhole ich hier nicht. Es steht in meinem Cucumber Artikel und im Rails Testing Leitfaden. Der Compliance Blickwinkel ist enger.

Kein Produktions Release geht raus, bevor die gesamte Suite grün gelaufen ist. Auf Staging findest du Fehler, in Produktion nicht. Und der Lauf selbst, wann, auf welchem Commit, mit welcher Coverage, wird aufgezeichnet. In den Projekten, die ich liefere, müssen die vollen TDD und BDD Suiten bestehen, bevor etwas die Produktion erreicht, und die Läufe werden samt Coverage als Nachweis aufgezeichnet.¹⁷

Genau ums Aufzeichnen geht es. "Wir haben Tests" ist eine Behauptung. "Version 2026.11.3 ging nach einem Lauf von 1.412 Szenarien bei 84 % Coverage an diesem Tag live, Bericht anbei" ist ein Nachweis, und genau danach sucht die Frage des Prüfers zur Änderungskontrolle. PCI DSS verlangt dasselbe in seiner Anforderung zum Änderungsmanagement.¹³

Verhaltensgetriebene Szenarien haben eine zweite Aufgabe. Sie stehen in Alltagssprache, also kann die Testerin des Kunden sie lesen und bestätigen, dass sie beschreiben, was das Geschäft will. Kunden lesen diese Tests in Alltagssprache in ihrem Kundenhub.²⁰ Die Bestätigung auf Staging wird erfasst, danach nimmt die Person mit Entscheidungsbefugnis das Release ab. Anfrage, Tests, Bestätigung auf Staging, Abnahme, Release, Prüfung: Jeder Schritt hat einen Namen und ein Datum.

Das klingt schwer. In der Praxis sind es ein paar Klicks pro Release, und es ist der Unterschied zwischen einer Änderungshistorie, die etwas bedeutet, und einer, die nichts bedeutet.

Ein Audit Log, mit dem ein Versicherer arbeiten kann

Fast jede Anwendung protokolliert irgendetwas. Kaum etwas davon hilft, wenn es darauf ankommt.

Wenn ein Versicherer einen Schaden prüft oder ein Prüfer einer Abweichung nachgeht, sind die Fragen konkret: Wer hat diesen Datensatz geändert, wann, von wo, und wie sah er vorher aus? Logs voller Antwortzeiten und Stack Traces beantworten das nicht. Ein Audit Trail schon: eine nur ergänzbare Aufzeichnung, wer was an welchem Geschäftsobjekt getan hat, getrennt von den Daten selbst.

Ein brauchbares Audit Log erfasst jede Aktion, die einen buchhaltungsrelevanten Datensatz, ein Benutzerkonto, eine Berechtigung, ein Dokument oder ein Release berührt, jeweils mit Akteur, Ziel, Änderung und Zeitstempel, dazu Anmeldungen und fehlgeschlagene Anmeldungen. Die Aufbewahrungsregel ist aufgeschrieben. PCI DSS setzt für alle in seinem Anwendungsbereich eine Untergrenze von zwölf Monaten, die letzten drei sofort verfügbar.¹³ Ein Release Register und ein Audit Log gehören zu dem, was ich im Kundenhub als Nachweis aufführe.²⁰

Und es muss exportierbar sein. Ein Versicherer will sich nicht in deinen Adminbereich einloggen. Er will eine Datei, gefiltert nach Zeitraum und System, die sein eigener Analyst lesen kann. Bau diesen Export einmal in Ruhe, nicht um zwei Uhr nachts mitten in einem Vorfall.

Es gibt einen DSGVO Haken. Audit Logs enthalten personenbezogene Daten, mindestens die Identität des Akteurs, also brauchen sie eine Rechtsgrundlage und eine Speicherdauer wie alles andere. Erwägungsgrund 49 erkennt Netz und Informationssicherheit als berechtigtes Interesse an, das deckt es gut ab, aber trag es nach Artikel 30 in dein Verzeichnis der Verarbeitungstätigkeiten ein.¹ Ein Audit Log, das du nach der DSGVO nicht erklären kannst, ist selbst ein Risiko.

Der Tresor: unterschriebene Dokumente an einem Ort

Das letzte Stück ist das am wenigsten technische und das, das am häufigsten fehlt.

Jede Zusammenarbeit erzeugt Dokumente, nach denen irgendwann jemand fragt: der unterschriebene Vertrag, der Auftragsverarbeitungsvertrag, die Versicherungspolicen, die Klauseln zum Offboarding, die Freigabe PDFs der kritischen Pfade. In den meisten kleinen Firmen liegen sie in Mailanhängen, in einem geteilten Ordner mit wechselnden Dateinamen und im Ablagesystem der Kanzlei.

Ein Tresor legt sie an einen Ort, pro Kunde, mit unterschriebenen Fassungen, die nicht überschrieben werden können. In meinem Kundenportal liegen Verträge, Bedingungen und Versicherungsdokumente in einem Tresor, unterschriebene Versionen sind für immer gesperrt, jeder Zugriff und Download wird protokolliert, und das Onboarding enthält einen formalen Prüf und Zustimmungsschritt, der direkt an das Legal Team des Kunden gehen kann.¹⁷

Fragt der Einkauf nach deinem Versicherungsnachweis und deinem Auftragsverarbeitungsvertrag, ist die Antwort ein Link, kein Nachmittag. Die Käuferseite dieser Frage habe ich in wie Auftragsverarbeiter dich zu Strafen führen können beschrieben. Der Tresor ist das Spiegelbild: der Lieferant zu sein, der antworten kann.

Ein Beispiel: ein Release an einem normalen Dienstag

Zurück zu einer erfundenen Firma, diesmal einem Grazer Anbieter von Rechnungssoftware unter rechnung.example, um zu zeigen, wie leicht die Routine ist.

Die Testerin des Kunden schreibt eine Anfrage: Der Rechnungsexport soll die Umsatzsteuer Identifikationsnummer des Kunden enthalten. Das Szenario wird in Alltagssprache geschrieben, die Tests folgen. Die Tests laufen rot, der Code macht sie grün, und die ganze Suite läuft, bevor die Änderung auf Staging geht. Die Testerin prüft auf Staging und bestätigt. Die zeichnungsberechtigte Person nimmt ab. Das Release geht als 2026.11.4 raus, mit einer Zeile unter "geändert", und die Ampel springt auf Gelb.

Brakeman und das Abhängigkeitsaudit liefen schon beim Build und bestanden. Am Abend läuft ein Injection Scan gegen die Produktion, die Prüfung wird gegen 2026.11.4 mit Link zum Bericht erfasst, und die Ampel wird grün. Hätte die Änderung die Umsatzsteuerberechnung selbst berührt, hätte der verifizierte kritische Pfad angeschlagen, und die zeichnungsberechtigte Person hätte vor dem Release erneut freigegeben.

Der Aufwand über die eigentliche Arbeit hinaus liegt bei vielleicht zwanzig Minuten. In diesen zwanzig Minuten sind die Fragen aller sechs Zielgruppen für dieses Release beantwortet.

Die Version für Montagmorgen

Für den Anfang brauchst du kein Portal. Du brauchst die Gewohnheit und einen Ort zum Aufschreiben. Hier ist eine Fassung, mit der jede kleine Firma nächste Woche beginnen kann.

Tagge jedes Produktions Release in Git. Ein Tag mit der Versionsnummer und eine Nachricht mit den drei Listen. Das ist dein Release Register. Deployst du von einem Branch, tagge den Commit, den du ausgerollt hast.

Führ eine Tabelle mit einer Zeile pro Release. Version, Datum, ein Satz zur Änderung, wer freigegeben hat, Ergebnis der Testsuite, ob eine Sicherheitsprüfung stattfand, ihr Datum und ein Link zum Bericht. Fünf Minuten pro Release.

Bau Brakeman und ein Abhängigkeitsaudit in deinen Build ein, oder die Gegenstücke für deinen Stack, und lass den Build bei neuen Funden fehlschlagen. Einmal ein Vormittag Arbeit, und es läuft für immer.

Lass einen Penetrationstest auf der aktuellen Version machen und leg den Bericht mit der Versionsnummer im Dateinamen ab. Notier für jedes spätere Release in der Tabelle, ob die Änderung im Umfang dieses Tests lag oder einen neuen Blick braucht.

Fang ein Audit Log an, falls deine Anwendung keins hat. Für Rails gibt es ausgereifte Bibliotheken, die das an einem Nachmittag erledigen. Mach es nur ergänzbar und schreib auf, wie lange du es aufbewahrst.

Leg unterschriebene Dokumente in einen Ordner mit festem Benennungsschema und ohne Löschungen: Vertrag, Auftragsverarbeitungsvertrag, Versicherungspolicen und eine Textdatei, die auflistet, was da ist und wann es unterschrieben wurde.

Schreib eine einseitige Richtlinie, die all das beschreibt. Keine Absichten, sondern was du tatsächlich tust. Sie existiert, damit ein Fragebogen auf sie verweisen kann, und sie ist nur etwas wert, wenn die Tabelle beweist, dass du dich daran hältst.

Dieses Minimum trägt eine Firma mit fünf Leuten durch die Verlängerung beim Versicherer, einen NIS2 Lieferantenbrief und die meisten Einkaufsformulare. Durch eine Prüfung kritischer Finanzlogik trägt es dich nicht, und es fängt bei etwa drei Systemen und zwei Leuten, die releasen, an zu schmerzen, weil einer Tabelle niemand mehr traut, sobald zwei Leute sie bearbeiten.

Wie es wächst

Ein Portal ist das, was aus der Tabelle wird, wenn die Tabelle nicht mehr reicht, und die Übergänge sind vorhersehbar.

Die Tabelle wird zum Register in einem System, wenn jemand anderes als die Person, die sie füllt, ihr vertrauen muss, meist der erste Kunde, der sie sehen will. Der Ordner mit Berichten wird zu verknüpften Prüfungen, wenn du mehr als eine Produktivanwendung betreibst und "ist die laufende Version getestet" pro Anwendung beantwortet werden muss. Die Ampel kommt, wenn die Inhaberin den Stand wissen will, ohne zu fragen. Verifizierte kritische Pfade kommen, wenn ein Prüfer zum ersten Mal nicht fragt, ob das System getestet wurde, sondern ob seine Regel die richtige ist. Der Export des Audit Logs kommt, wenn ein Versicherer zum ersten Mal danach fragt, und du hättest ihn lieber vorher. Der Tresor kommt, wenn das dritte Einkaufsformular im Jahr nach denselben vier Dokumenten fragt.

Nichts davon muss gebaut sein, bevor du es brauchst. Alles davon muss gebaut sein, bevor die Mail ankommt, und das ist etwas anderes. Die Mindestfassung oben verschafft dir die Zeit für den Rest.

Was ich in dieser Größe lassen würde

Zuerst die Zertifizierung. ISO/IEC 27001 ist eine echte Norm und ein echtes Signal, und für eine Firma unter fünfzig Leuten auch ein erhebliches Projekt an Zeit und Geld, für ein Zertifikat, das die meisten deiner Kunden nicht verlangen.¹⁴ Mach zuerst das Programm oben. Macht ein Kunde die Zertifizierung zur Bedingung eines Vertrags, der sie bezahlt, dann mach sie, und du wirst feststellen, dass das meiste Fundament schon steht.

Werkzeuge vor Gewohnheiten. Eine ganze Branche verkauft kleinen Firmen Plattformen zur Compliance Automatisierung. Die sind in Ordnung. Sie nützen nur nichts, wenn niemand Releases taggt und Tests erfasst, und wenn alle es tun, hält eine Tabelle länger, als die Anbieter dir glauben machen wollen.

Richtlinien, die niemand liest. Eine vierzigseitige Sicherheitsrichtlinie, für den Fragebogen geschrieben, die eine Firma beschreibt, die es nicht gibt, ist schlechter als eine einseitige, die stimmt. Prüfer merken das, und wenn etwas schiefgeht, ist eine Richtlinie, an die du dich nicht gehalten hast, ein Beweis gegen dich.

Worum es eigentlich geht

Das Programm dreht sich nicht in erster Linie um Fragebögen. Es macht Releases besser. Wer weiß, dass jedes Release versioniert, getestet, geprüft und aufgezeichnet wird, released bewusst. Kritische Logik in Alltagssprache aufzuschreiben findet Lücken im Gespräch, bevor sie Code sind. Ein Audit Log klärt "wer hat den Preis geändert" in einer Minute statt in einer Woche Mailarchäologie. Ein Tresor macht aus einer Due Diligence einen Link statt einer Suche.

Compliance ist ein Nebenprodukt davon, Software ordentlich zu betreiben und es aufzuschreiben. Der Fragebogen ist nur der Moment, in dem sich das Aufschreiben bezahlt macht.

Footnotes

1. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 5 Absatz 2, Artikel 30 und 32 sowie Erwägungsgrund 49, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679 ↩ ↩² ↩³

2. Europäisches Parlament und Rat, Richtlinie (EU) 2022/2555 (NIS2 Richtlinie), Artikel 21 und 23, ABl. L 333, 27. Dezember 2022, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32022L2555 ↩ ↩²

3. Republik Österreich, Netz und Informationssystemsicherheitsgesetz 2026 (NISG 2026), BGBl. I Nr. 94/2025, 23. Dezember 2025, in Kraft seit 1. Oktober 2026, https://www.ris.bka.gv.at/Dokumente/BgblAuth/BGBLA_2025_I_94/BGBLA_2025_I_94.html ↩

4. Republik Österreich, Netz und Informationssystemsicherheitsgesetz 2026 (NISG 2026), § 32 Risikomanagementmaßnahmen im Bereich der Cybersicherheit, Rechtsinformationssystem des Bundes (RIS), https://www.ris.bka.gv.at/Dokumente/Bundesnormen/NOR40273893/NOR40273893.html ↩

5. Republik Österreich, NISG 2026, § 34 Berichtspflichten, Rechtsinformationssystem des Bundes (RIS), https://www.ris.bka.gv.at/Dokumente/Bundesnormen/NOR40273895/NOR40273895.html ↩

6. Republik Österreich, NISG 2026, § 33 Nachweis der Wirksamkeit von Risikomanagementmaßnahmen, Rechtsinformationssystem des Bundes (RIS), https://www.ris.bka.gv.at/Dokumente/Bundesnormen/NOR40273894/NOR40273894.html ↩

7. Bundesrepublik Deutschland, Gesetz zur Umsetzung der NIS 2 Richtlinie und zur Regelung wesentlicher Grundzüge des Informationssicherheitsmanagements in der Bundesverwaltung, Bundesgesetzblatt 2025 I Nr. 301, 5. Dezember 2025, https://www.recht.bund.de/bgbl/1/2025/301/VO.html ↩

8. Law Society Gazette, Ireland referred to CJEU over cyber bill, 8. Juli 2026, https://www.lawsociety.ie/gazette/top-stories/2026/july/ireland-referred-to-cjeu-over-cyber-bill/ und Government pledge on delayed cyber bill, 7. Oktober 2026, https://www.lawsociety.ie/gazette/top-stories/2026/october/government-pledge-on-delayed-cyber-bill/ ↩

9. Houses of the Oireachtas, Bills and Acts, geprüft am 11. November 2026, https://www.oireachtas.ie/en/bills/ ↩

10. The Data (Use and Access) Act 2025 (Commencement No. 9 and Transitional and Saving Provisions) Regulations 2026, SI 2026/1015, Inkraftsetzung der sections 118 und 119 (Information Commission) zum 30. September 2026, legislation.gov.uk, https://www.legislation.gov.uk/uksi/2026/1015/made ↩

11. Europäisches Parlament und Rat, Verordnung (EU) 2024/2847 (Cyberresilienzverordnung), Artikel 13, 14 und 71 sowie Anhang I, EUR Lex, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/deu ↩

12. PCI Security Standards Council, Just published: PCI DSS v4.0.1, 11. Juni 2024, https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1 ↩

13. PCI Security Standards Council, PCI DSS v4.0.1, Anforderungen 6.3.3, 6.5.1, 10.5.1 und 11.4, Dokumentenbibliothek, https://www.pcisecuritystandards.org/document_library/ ↩ ↩² ↩³ ↩⁴

14. International Organization for Standardization, ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection, Information security management systems, Requirements, Anhang A Kontrollen 8.8, 8.15, 8.25, 8.29 und 8.32, https://www.iso.org/standard/27001 ↩ ↩² ↩³

15. Europäisches Parlament und Rat, Richtlinie (EU) 2019/882 (European Accessibility Act), Artikel 2 und 31, EUR Lex, https://eur-lex.europa.eu/eli/dir/2019/882/oj/deu ↩

16. Republik Österreich, Bundesgesetz, mit dem ein Barrierefreiheitsgesetz erlassen sowie das Sozialministeriumservicegesetz geändert wird, BGBl. I Nr. 76/2023, 19. Juli 2023, https://www.ris.bka.gv.at/Dokumente/BgblAuth/BGBLA_2023_I_76/BGBLA_2023_I_76.html ↩

17. Keferboeck, So läuft jede Zusammenarbeit (professionelle Standards), veröffentlicht auf der Seite zur SaaS Entwicklung, https://keferboeck.com/de-at/product-and-services/saas-development ↩ ↩² ↩³ ↩⁴ ↩⁵

18. Brakeman, statischer Sicherheitsscanner für Ruby on Rails, https://brakemanscanner.org/ ↩

19. RubyGems.org, Gem bundler audit, https://rubygems.org/gems/bundler-audit ↩

20. Keferboeck, Warum Erfahrung zählt (Nachweise: Tests in Alltagssprache in deinem Kundenhub, kritische Pfade verifiziert und hinter Freigabe eingefroren, ein Release Register und ein Audit Log), https://keferboeck.com/de-at/product-and-services/saas-development ↩ ↩²