Compliance nachweisen: Release Register und Sicherheitstests pro Release

Die Mail auf die niemand vorbereitet ist

Es gibt einen Moment den ich in einem Dutzend kleiner Unternehmen beobachtet habe. Eine Mail kommt an, vom Einkauf eines großen Kunden, oder von der Versicherung zur Verlängerung, oder von einem Prüfer den eine Bank gebeten hat sich das Buchhaltungssystem anzusehen. Sie enthält einen Fragebogen. Frage vierzehn lautet ungefähr: Beschreiben Sie Ihren sicheren Entwicklungsprozess und legen Sie Nachweise über Sicherheitstests für die aktuelle Produktionsversion vor.

Und der Inhaber, der Sicherheit wirklich ernst nimmt, der für gutes Hosting zahlt und einen Entwickler hat der weiß was SQL Injection ist, merkt dass er nichts anhängen kann. Nicht weil nichts getan wurde. Weil nichts in einer Form aufgeschrieben wurde die jemand anderes prüfen könnte.

In diesem Artikel geht es darum diese Lücke zu schließen. Nicht um das Gesetz. Über den Cyber Resilience Act, NIS2 und die KI Verordnung habe ich anderswo geschrieben, und diese Artikel sagen dir was verlangt wird. Hier geht es um die langweilige Maschinerie die es einer kleinen Firma erlaubt, mit geradem Gesicht und einem PDF zu sagen: das haben wir veröffentlicht, das hat es getestet, hier ist der Bericht, und das ist die Version die gerade läuft.

Ich betreibe das für jeden Kunden in meinem Portal, von einer Energiegenossenschaft mit Buchhaltungslogik die ein Prüfer kontrolliert, über ein SaaS Produkt mit einer Handvoll Konzernkunden, bis zu Shops die einfach wollen dass ihre Versicherung ohne Kampf verlängert. Es ist nicht kompliziert. Es ist nur unerbittlich, und es funktioniert nur wenn es in die Art eingebaut ist wie Software veröffentlicht wird, statt angeschraubt zu werden wenn der Fragebogen kommt.

Was ein Nachweis eigentlich ist

Ich definiere das Wort, denn hier sitzt die meiste Verwirrung.

"Wir nehmen Sicherheit ernst" ist eine Behauptung. "Wir arbeiten nach Best Practice" ist eine Behauptung. "Unser Entwickler ist sehr sorgfältig" ist eine Behauptung. Eine Richtlinie die sagt dass Releases vor dem Deployment getestet werden ist auch eine Behauptung, und eine überraschend schwache, denn eine Richtlinie kann jeder schreiben.

Ein Nachweis ist ein Eintrag den ein Dritter prüfen kann ohne dir vertrauen zu müssen. Er hat ein Datum. Er nennt eine bestimmte Version eines bestimmten Systems. Er nennt wer die Sache gemacht hat und zeigt idealerweise auf das Artefakt das dabei entstanden ist. Er liegt an einem Ort an dem er nicht nachträglich still geändert werden konnte.

Der Unterschied klingt kleinlich, bis du auf der anderen Seite des Tisches sitzt. Ein Prüfer wird nicht dafür bezahlt dir zu glauben. Der Schadensbearbeiter einer Versicherung sucht, wenn etwas schiefgegangen ist und Geld auf dem Spiel steht, aktiv nach der Lücke zwischen dem was du bei der Verlängerung gesagt hast und dem was du zeigen kannst. Ein Einkäufer in einem Konzern hat eine Checkliste und eine Rechtsabteilung, und "vertrauen Sie uns" setzt kein Häkchen.

Das ganze Programm unten ist deshalb um eine Frage herum gebaut: Kann ich für jedes Produktionssystem, zu jedem Zeitpunkt, einen Eintrag vorlegen der sagt welche Version läuft, was sich darin geändert hat, wer sie wann auf Sicherheit getestet hat, und wo der Bericht liegt? Wenn ja, wird fast jeder Fragebogen den ich je gesehen habe zu einer Frage von Kopieren und Einfügen. Wenn nein, ist jeder Fragebogen ein Gerenne.

Die eine Gewohnheit an der alles hängt

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

Ich meine jedes Release. Nicht die großen. Nicht die mit einem Feature drin. Das Deployment am Dienstagnachmittag das einen Tippfehler behoben hat bekommt eine Version, denn nächsten Monat, wenn jemand fragt was sich zwischen der Version die der Pentester angeschaut hat und der die jetzt läuft geändert hat, muss die Antwort eine Liste sein und kein Schulterzucken.

Das Versionsschema ist weniger wichtig als die Disziplin, aber wähle eines und schreib es auf. Für Produkte die nach Plan erscheinen funktioniert semantische Versionierung, das vertraute Muster 2.4.1, gut. Für Anwendungen die laufend ausgerollt werden, mehrmals die Woche, bin ich auf Kalenderversionen umgestiegen: Jahr, Monat und ein Zähler, also ist 2026.11.3 das dritte Release im November 2026. Es sagt dir auf einen Blick wie alt die laufende Version ist, und genau das fragt eine Versicherung.

Die Release Notes sind kein Marketing. Sie sind drei Listen: was hinzugekommen ist, was sich geändert hat, was entfernt wurde. Dazu ein Zeitstempel und wer die Freigabe erteilt hat. Im Portal das ich für Kunden betreibe ist das ein Release Register: ein Eintrag pro Produktionsrelease pro Projekt, für den Kunden sichtbar, als PDF auf Deutsch und Englisch exportierbar, damit es einem Prüfer in die Hand gegeben werden kann der das System nie gesehen 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.

Sicherheitstests sind eine Eigenschaft einer Version, nicht eine Richtlinie

Hier verschiebt sich das Denken, und es ist die Verschiebung die den Fragebogen leicht macht.

Die meisten kleinen Firmen, wenn sie Sicherheit überhaupt testen, denken daran als Ereignis. Wir hatten 2024 einen Pentest. Irgendwo liegt ein PDF. Das Problem ist dass das 2024 getestete System nicht mehr existiert. Es wurde seitdem über vierzig Mal ausgerollt. Der Bericht ist ein Nachweis dafür dass ein System das nicht mehr läuft einmal einigermaßen sicher war.

Das Programm behandelt Sicherheitstests als etwas das gegen eine Version festgehalten wird. Jede Releaseversion muss auf Sicherheit getestet werden, bevor sie live geht oder zeitnah danach. Der Eintrag sagt: Version 2026.11.3 des Kundenportals, bewertet an diesem Datum, von dieser Person oder diesem Werkzeug, das ist der Bericht, bestanden oder nicht.

Was die Bewertung enthält hängt von der Änderung und vom Stack ab. Für die Rails Anwendungen die ich baue ist die Basis:

Statische Analyse. Brakeman läuft bei jedem Build und lässt ihn bei neuen Warnungen mit hoher Konfidenz fehlschlagen. Es findet die langweiligen, häufigen, teuren Dinge: SQL aus Strings gebaut, nicht maskierte Ausgabe, Mass Assignment, Weiterleitungen auf vom Nutzer gelieferte URLs. Es ist kostenlos und dauert eine Minute. Es gibt keine Ausrede das nicht zu haben.

Prüfung der Abhängigkeiten. Bundler Audit gegen die Datenbank bekannter Schwachstellen, plus das Gegenstück für die JavaScript Seite. Ein erschreckender Anteil echter Einbrüche kommt über eine Bibliothek die seit zwei Jahren niemand angeschaut hat. Auch das läuft bei jedem Build.

Injection und Cross Site Scripting Durchläufe. Automatisiertes Scannen der laufenden Anwendung, nicht nur des Codes, gegen die üblichen Injection Klassen. Hier verdienen die automatisierten Werkzeuge ihr Geld, weil sie die tausend Varianten ausprobieren die ein Mensch nicht durchgehen würde.

Ein Penetrationstest. Eine Person, mit einem Auftrag, die versucht reinzukommen. Für ein großes Release oder ein neues System ist das die volle Übung. Für ein Routinerelease kann es ein gezielter Blick auf das sein was sich geändert hat. Der Punkt ist dass ein Mensch mit Absicht draufgeschaut und aufgeschrieben hat was er gefunden hat.

Last und Belastbarkeitstests wo relevant. Wenn das System eines ist dessen Ausfall Geld kostet, und NIS2 kümmert sich ausdrücklich um Verfügbarkeit, dann hat jemand es so weit belastet bis es umgefallen ist und aufgeschrieben wo das war.

Die Berichte liegen im Dokumentations Repository des Produkts, in Git, mit der Version auf die sie sich beziehen. Dieser Ort ist Absicht. Ein Git Repository ist ein Kassenbuch. Jede Änderung hat Zeitstempel und Urheber, und die Geschichte zu verändern ist schwer und sichtbar. Wenn ein Prüfer fragt "woher weiß ich dass dieser Bericht nicht letzte Woche geschrieben wurde", ist die Commit Historie die Antwort.

Und das Portal verlinkt darauf. Jedes Kundenunternehmen hat einen Bereich Cyber Security der jede Produktionsanwendung auflistet, die aktuell laufende Version, die letzte Bewertung und einen Link zum Bericht. Wenn ich ausrolle, setze ich die aktuelle Version im Portal hoch. Wenn die Bewertung fertig ist, trage ich sie ein. Zwei Klicks, und die Nachweiskette ist intakt.

Die Ampel

Das ist der Teil den Kunden am liebsten mögen, und er ist der einfachste.

In der Seitenleiste des Portals hat jedes Unternehmen eine Ampel. Rot heißt für dieses Unternehmen wurde noch nie eine Sicherheitsbewertung eingetragen. Orange heißt die Version die gerade in Produktion läuft wurde nicht erfolgreich bewertet, was meistens bedeutet dass wir etwas ausgerollt haben und die Bewertung noch aussteht. Grün heißt jede aktuelle Version jeder Produktionsanwendung hat eine bestandene Bewertung im Register.

Das ist die ganze Regel. Sie lässt sich nicht durch eine schöne Richtlinie austricksen. Sie wird nicht grün weil sich jemand gut fühlt was Sicherheit angeht. Sie ist grün wenn die laufenden Versionen getestet wurden und die Einträge existieren, und sie springt auf Orange in dem Moment in dem ein Release rausgeht, bis die Bewertung nachgezogen ist.

Sie funktioniert weil sie Compliance von einer abstrakten Pflicht zu einem Zustand macht den ein Inhaber mit einem Blick sieht und über den er sich leicht ärgern kann wenn er falsch ist. Drei Wochen Orange ist ein Gespräch. Rot ist ein Notfall. Grün ist das was du als Screenshot an den Fragebogen hängst.

Ich will ehrlich sein über den Anreiz den sie schafft: sie lässt mich weniger beiläufig ausrollen. Wenn jedes Release die Ampel auf Orange stellt bis ich die Bewertung gemacht habe, bündle ich kleine Änderungen und teste ordentlich. Das ist genau das Verhalten das der Cyber Resilience Act mit seinen Pflichten zum Umgang mit Schwachstellen erzeugen will, und es stellt sich heraus dass ein farbiger Punkt das zuverlässiger schafft als eine Verordnung.

Wer fragt, und was er wirklich will

Ich bin mir bei dieser Form so sicher weil ich genug Fragebögen durchgesessen habe um zu merken dass es immer dieselben sechs Fragen in verschiedenen Kleidern sind.

Der Prüfer. Meistens ein Wirtschaftsprüfer, oder ein IT Prüfer der für einen arbeitet, der Gewissheit braucht dass ein System das Finanzzahlen produziert tut was es behauptet und nicht manipuliert wurde. Er fragt: welche Version läuft, welche Kontrollen gibt es über Änderungen daran, wer kann es ändern, und gibt es einen Eintrag für jede Änderung. Er fragt auch nach der Logik selbst, und da kommen die geprüften kritischen Pfade ins Spiel, siehe unten. Sehen will er ein Änderungsprotokoll, Zugriffskontrollen und Nachweise dass vor Releases Tests gelaufen sind. Ein Release Register mit angehängten Testläufen ist fast die ganze Antwort.

Die Versicherung. Fragebögen für Cyberversicherungen haben sich in den letzten Jahren angeglichen, und sie fragen: nutzt ihr Multi Faktor Authentifizierung, patcht ihr innerhalb eines definierten Fensters, habt ihr Backups deren Wiederherstellung getestet ist, protokolliert ihr Zugriffe und Änderungen, hattet ihr in den letzten zwölf Monaten einen Penetrationstest, und habt ihr einen Plan für Sicherheitsvorfälle. Bei der Verlängerung wollen sie Häkchen. Im Schadensfall wollen sie den Beweis dass die Häkchen an dem Tag gestimmt haben. Der Bewertungseintrag mit Datum und der Audit Log Export sind das was die Häkchen verteidigbar macht.

Die NIS2 Lieferantenanfrage. Wenn einer deiner Kunden unter NIS2 fällt, ist er verpflichtet Risiken in seiner Lieferkette zu steuern, was bedeutet dass er dir einen Brief schickt. Er fragt ob du einen Prozess für den Umgang mit Schwachstellen hast, wie schnell du patchst, ob du Releases testest, ob du ihn innerhalb einer festgelegten Zeit über Vorfälle informieren kannst, und ob du Nachweise liefern kannst. Das Release Register und die Bewertung pro Version sind die Nachweise, und die Meldepflicht ist ein Absatz im Vorfallplan.

Der Konzerneinkauf. Das längste Formular, meist eine Tabelle mit zweihundert Zeilen, von denen hundertfünfzig auf eine Firma deiner Größe nicht zutreffen und der Rest nach sicherer Entwicklung, Zugriffskontrolle, Verschlüsselung, Protokollierung, Geschäftskontinuität und Unterauftragsverarbeitern fragt. Der Trick bei Einkaufsformularen ist dass ein "nein, aber" mit Nachweis ein "ja" ohne Nachweis schlägt. "Wir haben kein eigenes Sicherheitsteam, aber jedes Release wird bewertet, hier ist das Register und hier sind die letzten drei Berichte" kommt durch. "Ja, wir nehmen Sicherheit ernst" bekommt eine Rückfrage.

Die Datenschutzbehörde. Seltener, aber wenn eine DSGVO Beschwerde oder eine Datenpanne dich vor eine Aufsichtsbehörde bringt, fragt sie welche technischen und organisatorischen Maßnahmen du nach Artikel 32 hattest und ob du sie nachweisen kannst. Nachweisen ist das entscheidende Wort. Artikel 32 verlangt keine Perfektion. Er verlangt angemessene Maßnahmen und die Fähigkeit sie zu zeigen. Dasselbe Register, dieselben Berichte.

Die Bank. Zunehmend stellen Kreditgeber und Zahlungsanbieter eine gekürzte Version der Versicherungsfragen bevor sie Konditionen einräumen.

Sechs Adressaten. Ein Register, ein Satz Bewertungseinträge, ein Audit Log, ein Tresor mit unterschriebenen Dokumenten. Das ist kein Zufall. Sie stellen am Ende alle dieselbe Frage: Kannst du es mir zeigen, oder muss ich dir glauben.

Geprüfte kritische Pfade, wenn die Logik selbst das Risiko ist

Manche Systeme haben ein Stück Logik das, wenn es falsch ist, kein Bug sondern eine Haftung ist. Die Arithmetik die die Kosten einer Energiegenossenschaft auf ihre Mitglieder verteilt. Die Zuordnung die entscheidet welche Rechtsdokumente ein Kunde für welches Produkt akzeptieren muss. Eine Tarifberechnung. Eine Provisionsaufteilung.

Für diese reicht es nicht zu testen dass der Code tut was der Entwickler beabsichtigt hat, denn die Frage ist ob das was der Entwickler beabsichtigt hat das ist was der Kunde und der Prüfer des Kunden für die Regel halten. Deshalb hat das Programm einen zweiten Mechanismus: einen geprüften kritischen Pfad, einen Prüfpfad.

Ein Prüfpfad ist eine Beschreibung in klarer Sprache wie ein Stück kritischer Logik funktioniert, für den Kunden geschrieben und nicht für Entwickler, zusammen mit den ausführbaren Tests die beweisen dass das System genau das tut. Der Kunde liest sie und gibt sie frei. Im Moment der Freigabe wird sie eingefroren: der Inhalt wird gehasht, der Hash, die freigebende Person und der Zeitstempel werden festgehalten, und ab dann wird jede Änderung an der zugrunde liegenden Logik oder an der Beschreibung markiert. Eine markierte Änderung ist für sich kein Releaseblocker, aber sie ist sichtbar, sie kann eine erneute Freigabe des Kunden erfordern, und in manchen Fällen die erneute Freigabe eines Dritten.

Das Portal erzeugt eine Übersichtsseite und ein PDF, auf Deutsch und Englisch, das einem Prüfer übergeben werden kann. Was der Prüfer bekommt ist nicht "der Entwickler sagt es funktioniert", sondern "hier ist die Regel in Worten, hier ist die Freigabe des Kunden für diese Regel an diesem Datum, hier sind die Tests die prüfen dass das System ihr folgt, und hier ist der Beweis dass sich seitdem nichts geändert hat".

Ich habe festgestellt dass das etwas Unerwartetes bewirkt. Die Beschreibung in klarer Sprache zu schreiben erzwingt ein Gespräch zwischen dem Kunden und mir darüber was die Regel eigentlich ist, und ungefähr in einem von drei Fällen findet dieses Gespräch einen Fall an den niemand gedacht hatte. Das Compliance Artefakt entpuppt sich als Entwurfswerkzeug.

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

Ich wiederhole hier nicht das ganze Argument für testgetriebene und verhaltensgetriebene Entwicklung, das habe ich in meinem Cucumber Artikel und im Leitfaden zum Testen in Rails getan. Der Compliance Blickwinkel ist enger und lautet so.

Kein Produktionsrelease geht raus bevor die vollständige Testsuite grün gelaufen ist. Staging ist ausgenommen, denn auf Staging findet man es heraus. Produktion nicht. Und dass die Suite gelaufen ist, wann, auf welchem Commit, mit welcher Abdeckung, wird im Portal als Testlauf festgehalten, dem Unternehmen und der Anwendung zugeordnet, mit einem Link zum Bericht.

Der Grund es festzuhalten statt es nur zu tun ist derselbe wie bei allem anderen hier. "Wir haben Tests" ist eine Behauptung. "Version 2026.11.3 wurde nach einem Lauf von 1.412 Szenarien mit 84 Prozent Abdeckung an diesem Datum veröffentlicht, Bericht anbei" ist ein Nachweis, und zufällig genau das wonach die Prüferfrage zu Änderungskontrollen sucht.

Die verhaltensgetriebenen Szenarien haben eine zweite Rolle. Sie sind in klarer Sprache geschrieben, damit der Tester des Kunden, und ich bestehe darauf dass jeder Kunde einen benennt, sie lesen und bestätigen kann dass sie beschreiben was das Geschäft will. Diese Bestätigung, auf Staging, vor dem Release, wird ebenfalls festgehalten. Dann nimmt die zeichnungsberechtigte Person, die mit der Befugnis das Release anzunehmen, es an. Anfrage, Tests, Bestätigung auf Staging, Annahme, Release, Bewertung. 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 es nicht tut.

Audit Logging das eine Versicherung wirklich nutzen kann

Die meisten Anwendungen haben irgendeine Protokollierung. Fast nichts davon ist nützlich wenn es darauf ankommt.

Wenn eine Versicherung einen Schaden prüft, oder ein Prüfer einer Unstimmigkeit nachgeht, sind die Fragen konkret: wer hat diesen Datensatz geändert, wann, von wo, und was stand vorher drin. Anwendungslogs voller Antwortzeiten und Stack Traces beantworten das nicht. Was es beantwortet ist ein Audit Trail: ein nicht veränderbarer Eintrag darüber wer was mit welchem Geschäftsobjekt gemacht hat, getrennt von den Daten selbst aufbewahrt.

Im Portal wird jede Aktion die einen buchhaltungsrelevanten Datensatz, ein Benutzerkonto, eine Berechtigung, ein Dokument oder ein Release berührt als Audit Ereignis geschrieben, mit handelnder Person, Ziel, Änderung und Zeitstempel. Anmeldungen und fehlgeschlagene Anmeldungen werden separat festgehalten. Die Aufbewahrungsregel ist aufgeschrieben: Ereignisse werden nur angefügt, nichts löscht sie, und sie werden über jedes regulatorische Minimum hinaus für eine definierte Zeit aufbewahrt.

Und sie sind exportierbar. Das ist der Teil den die meisten Systeme auslassen. Eine Versicherung will sich nicht in deinen Admin einloggen. Sie will eine Datei, gefiltert nach Zeitraum und System, die ihr eigener Analyst lesen kann. Der Export existiert genau deshalb, und ich baue ihn lieber einmal als um zwei Uhr morgens während eines Vorfalls.

Es gibt hier eine DSGVO Falte die es zu benennen gilt. Audit Logs enthalten personenbezogene Daten, mindestens die Identität der handelnden Person, also brauchen sie wie alles andere eine Rechtsgrundlage und eine Aufbewahrungsregel. Das berechtigte Interesse an Sicherheit und Nachvollziehbarkeit deckt das bequem ab, aber schreib es ins Verarbeitungsverzeichnis. Ein Audit Log das du unter der DSGVO nicht erklären kannst ist selbst eine Haftung.

Der Tresor: unterschriebene Dokumente an einem Ort

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

Jeder Auftrag erzeugt Dokumente nach denen irgendwann jemand fragt: der unterschriebene Vertrag, der Auftragsverarbeitungsvertrag, die Versicherungsbestätigungen, die Offboarding Klauseln, die Freigabe PDFs der Prüfpfade. In den meisten kleinen Firmen liegen die in Mailanhängen, in einem Dropbox Ordner mit uneinheitlicher Benennung und im Ablagesystem des Anwalts.

Das Portal hat pro Unternehmen einen Dokumententresor. Unterschriebene Verträge zwischen den Parteien, Versicherungsdokumente, die Nachweise für Berufshaftpflicht und Betriebshaftpflicht, und die Rechts und Releasedokumente die das Programm selbst erzeugt, alles an einem Ort, und der Kunde sieht seine eigenen. Unterschriebene Dokumente sind als unveränderlich markiert und tragen die Metadaten der Signatur, damit niemand still eine neue Version eines Vertrags über die alte lädt.

Wenn der Einkauf nach deiner Versicherungsbestätigung und deinem Auftragsverarbeitungsvertrag fragt, ist die Antwort ein Link und kein Nachmittag. Über die Lieferantenseite dieser Frage habe ich in wie Auftragsverarbeiter dich zu Strafen führen können geschrieben, und der Tresor ist das Spiegelbild: der Lieferant sein der antworten kann.

Wie das an einem normalen Dienstag aussieht

Ich mache es konkret, denn eine Liste von Mechanismen klingt schwerer als die Sache ist.

Der Tester eines Kunden schreibt eine Anfrage ins Portal: der Rechnungsexport soll die UID Nummer des Kunden enthalten. Ich schreibe das Verhaltensszenario und die Tests. Die Tests laufen rot, ich mache sie grün, die Suite läuft auf dem Branch, die Änderung geht auf Staging. Der Tester prüft sie auf Staging und bestätigt. Die zeichnungsberechtigte Person nimmt an. Ich rolle aus, die Version springt auf 2026.11.4, die Release Notes bekommen die eine Zeile, die Ampel wird orange. Brakeman und die Abhängigkeitsprüfung sind beim Build gelaufen und haben bestanden. Ich lasse am Abend den Injection Durchlauf gegen Produktion laufen, trage die Bewertung ein, verlinke den Bericht, und die Ampel ist wieder grün. Hätte die Änderung die Umsatzsteuerberechnung selbst berührt, hätte der Prüfpfad angeschlagen und die zeichnungsberechtigte Person hätte ihn vor dem Release erneut freigegeben.

Zusätzlicher Aufwand über die eigentliche Arbeit hinaus: vielleicht zwanzig Minuten. Und in diesen zwanzig Minuten ist jede Frage der sechs Adressaten oben für dieses Release bereits beantwortet.

Die Montagmorgen Version

Du brauchst mein Portal nicht um das zu tun. Du brauchst die Gewohnheit und einen Ort zum Aufschreiben. Hier ist die Version mit der jede kleine Firma nächste Woche anfangen kann.

Markiere jedes Produktionsrelease in Git mit einem Tag. Ein Tag mit der Versionsnummer und einer Nachricht mit den drei Listen. Das ist dein Release Register, und Git ist ein vollkommen brauchbares Kassenbuch. Wenn du von einem Branch ausrollst, markiere den Commit den du ausgerollt hast.

Führe eine Tabelle mit einer Zeile pro Release. Version, Datum, was sich in einem Satz geändert hat, wer freigegeben hat, Ergebnis der Testsuite, Sicherheitsbewertung gemacht ja oder nein, Datum der Bewertung, Link zum Bericht. Fünf Minuten pro Release.

Nimm Brakeman und eine Abhängigkeitsprüfung in deinen Build auf. Oder die Gegenstücke für deinen Stack. Lass den Build bei neuen Funden fehlschlagen. Das ist einmal ein Vormittag Arbeit und läuft dann für immer.

Lass einen Penetrationstest der aktuellen Version machen und lege den Bericht in einen Ordner mit der Versionsnummer im Dateinamen. Dann schreibst du für jedes Release danach in die Tabelle ob die Änderung von diesem Test abgedeckt war oder einen neuen Blick braucht.

Fang ein Audit Log an wenn deine Anwendung keines hat. Für Rails gibt es ausgereifte Bibliotheken die das an einem Nachmittag erledigen. Mach es nur anfügbar. Schreib auf wie lange du es aufbewahrst.

Leg die unterschriebenen Dokumente in einen Ordner mit festem Benennungsschema und ohne Löschungen. Vertrag, Auftragsverarbeitungsvertrag, Versicherungsnachweise, und eine Textdatei die auflistet was drin ist und wann es unterschrieben wurde.

Schreib eine einseitige Richtlinie die das Obige beschreibt. Keine Absichtserklärungen. Was du tatsächlich tust. Die Richtlinie existiert damit ein Fragebogen darauf verweisen kann, und sie ist nur etwas wert wenn die Tabelle beweist dass du dich daran hältst.

Das ist das ganze Minimum. Es bringt eine Firma mit fünf Leuten durch die Verlängerung bei der Versicherung, einen NIS2 Lieferantenbrief und die meisten Einkaufsformulare. Es bringt dich nicht durch eine Wirtschaftsprüfung kritischer Logik, und es fängt ungefähr an dem Punkt an weh zu tun an dem du drei Systeme und zwei Leute hast die ausrollen, denn der Tabelle wird in dem Moment nicht mehr vertraut in dem zwei Leute sie bearbeiten.

Wie es wächst

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

Die Tabelle wird zu einem Register in einem System, wenn jemand anderes als die Person die sie ausfüllt ihr vertrauen muss. Meistens ist das der erste Kunde der sie sehen will.

Der Ordner mit Berichten wird zu verknüpften Bewertungen, wenn du mehr als eine Produktionsanwendung hast und die Frage "ist die laufende Version getestet" pro Anwendung statt pro Unternehmen beantwortet werden muss.

Die Ampel erscheint, wenn der Inhaber den Zustand wissen will ohne zu fragen.

Prüfpfade erscheinen, wenn ein Prüfer zum ersten Mal nicht fragt ob das System getestet wurde, sondern ob die Regel die es umsetzt die richtige Regel ist.

Der Audit Log Export erscheint, wenn eine Versicherung oder ein Prüfer zum ersten Mal einen verlangt, und du hättest ihn lieber vorher.

Der Tresor erscheint, wenn das dritte Einkaufsformular in einem Jahr nach denselben vier Dokumenten fragt.

Nichts davon muss gebaut sein bevor du es brauchst. Alles davon muss gebaut sein bevor die Mail kommt, was etwas anderes ist, und die ehrliche Antwort für die meisten Firmen ist dass die Minimalversion oben dir die Zeit kauft den Rest zu bauen.

Womit ich mich nicht aufhalten würde

Ein paar Dinge die in Compliance Gesprächen auftauchen und die ich in dieser Größe liegen lassen würde.

Zertifizierung. ISO 27001 ist eine echte Sache und ein echtes Signal, und für ein Unternehmen unter fünfzig Leuten ist es auch ein Jahr der Zeit einer Führungskraft und ein fünfstelliger Betrag, für ein Abzeichen das die meisten deiner Kunden nicht verlangen werden. Mach zuerst das Programm oben. Wenn ein Kunde die Zertifizierung zur Bedingung eines Vertrags macht der sie bezahlt, mach sie dann, und du wirst feststellen dass das Programm die meiste Vorarbeit geleistet hat.

Werkzeuge vor Gewohnheiten. Es gibt eine ganze Industrie die kleinen Firmen Plattformen zur Compliance Automatisierung verkauft. Die sind in Ordnung. Sie sind auch nutzlos wenn niemand im Unternehmen Releases markiert und Tests festhält, und wenn es alle tun, funktioniert eine Tabelle länger als die Anbieter dich glauben lassen wollen.

Richtlinien die niemand liest. Eine vierzigseitige Informationssicherheitsrichtlinie die für den Fragebogen geschrieben wurde und ein Unternehmen beschreibt das es nicht gibt, ist schlimmer als eine einseitige Richtlinie 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 bei alldem geht

Ich möchte damit enden warum ich das wirklich tue, denn es geht nicht in erster Linie um Fragebögen.

Das Programm macht Releases besser. Zu wissen dass jedes Release versioniert, getestet, bewertet und festgehalten wird, lässt mich und die Entwickler mit denen ich arbeite bewusst ausrollen. Die Prüfpfade finden echte Fehler im Gespräch, bevor sie Code sind. Das Audit Log hat mehr "wer hat den Preis geändert" Streitigkeiten in einer Minute gelöst als jede Menge Mail Archäologie. Der Tresor hat einem Kunden während einer Due Diligence eine Woche Suchen erspart.

Die Compliance ist ein Nebeneffekt davon Software ordentlich zu betreiben und es aufzuschreiben. Die Fragebögen sind nur der Moment in dem sich das Aufschreiben bezahlt macht.

Wenn du das Portal mit einem Login sehen möchtest, oder eine zweite Meinung zu deiner eigenen Minimalversion willst, melde dich. Ich betreibe das für jeden Kunden in meinem Growth Programm und kann dir in einer Stunde sagen wo die Lücken sind.