Prüfungen und Fehlerregeln
Funktionstests, Sicherheitschecks oder Migrationsprüfungen: Sie bestimmen, welche Ergebnisse vorliegen müssen und was bei einem fehlgeschlagenen Check passiert.
Release Controls verstehen
Vom Code in den Betrieb. Mit klaren Freigaberegeln.
Release Controls sind Prüfungen und Freigaberegeln auf dem Weg vom geschriebenen Code zur Software im Betrieb. Sie legen fest, was geprüft wird, wer entscheiden darf und wie bei Fehlern reagiert wird.
- ÄnderungCode oder Konfiguration
- PrüfenErgebnisse zuordnen
- FreigebenVereinbarte Regel anwenden
- BetriebFreigegebene Version nutzen
Pflichtnachweis fehlt? Die vereinbarte Sperre oder das ausdrücklich vorgesehene Ausnahmeverfahren greift.
Wenn Coding Agents mehr Änderungen liefern, muss auch der Release-Prozess mithalten. Wiederkehrende Prüfungen, Nachweise und regelbasierte Freigaben lassen sich automatisieren. Sind die vereinbarten Bedingungen erfüllt, läuft der Release weiter. Menschliche Entscheidungen greifen dort, wo fachliches Urteil, unklare Risiken, Ausnahmen oder Ihre Freigabeanforderungen sie nötig machen.
Welche Kontrollen gehören dazu?
Diese Bausteine sind typisch. Welche Sie brauchen, hängt von Ihrem Produkt, den Geschäftsrisiken und den vorhandenen Abläufen ab.
Freigabe und Rollen
Wer darf entscheiden? Je nach Risiko braucht eine Änderung eine unabhängige Prüfung oder Freigabe. Zugriffsrechte setzen die vereinbarte Rollentrennung um.
Version und Nachweise
Ergebnisse und Freigabe gehören zum auszuliefernden Softwarepaket, dem Artefakt. Eine Versionsbezeichnung allein belegt diese Zuordnung nicht.
Stufen und Übergänge
Sie legen fest, welche Stufen ein Release durchläuft, etwa Test, Staging und Produktion, und unter welchen Bedingungen es weitergehen darf.
Ein Plan für Fehlerfälle
Rücknahme, Korrekturrelease oder Abschalten einer Funktion: Der Weg wird vorab vorbereitet. Datenänderungen sind nicht immer vollständig umkehrbar.
Der passende Zeitpunkt
Wartungsfenster oder Freigabepausen können kritische Geschäftszeiten schützen. Zeitpunkt und Ausnahmen werden passend zu Ihrem Betriebsrisiko vereinbart.
Cyber Resilience Act
CRA-Anforderungen im Release-Prozess umsetzen.
Eine SBOM und ein Schwachstellenbericht sind ein Anfang. Für die Arbeit am Produkt muss klar sein, zu welcher ausgelieferten Version sie gehören, wer eine Schwachstelle bewertet und wie die Entscheidung im Release-Prozess greift.
Ich beginne mit einem Produkt und einem Release-Weg. Mit Entwicklung, Security und Ihren CRA-Verantwortlichen kläre ich die Anforderungen und Zuständigkeiten. Die vereinbarte Verbesserung implementiere ich in Ihren bestehenden Systemen.
- SBOMs dem Release zuordnen
- Modul-SBOMs, Build-Artefakte und Produktversionen brauchen eine nachvollziehbare Verbindung. Ich stelle die vereinbarten Zuordnungen her und mache fehlende Informationen sichtbar. Die Qualität der Inventur bleibt eine eigene Prüfung.
- Betroffene Versionen und Verantwortliche finden
- Ich verbinde vorhandene Komponentendaten mit Produktversionen und zuständigen Personen. So erhält Ihr Team eine Grundlage für die Untersuchung einer Schwachstelle. Bewertung, Meldeentscheidung und Meldung bleiben bei Ihren dafür Verantwortlichen.
- Prüfungen und Entscheidungen wirksam machen
- Ich binde die vereinbarten Checks und Freigaberegeln in den Release-Weg ein. Gemeinsam erproben wir, ob er bei erfüllten Bedingungen weiterläuft und bei fehlenden oder fehlgeschlagenen Pflichtprüfungen stoppt. Ergebnisse und Entscheidungen bleiben dem jeweiligen Release zugeordnet.
Ihr Team erhält die Implementierung, Ergebnisse der Erprobung und eine Anleitung für die eigenständige Nutzung. Umfang, Voraussetzungen, Dauer und Festpreis vereinbaren wir vor dem Auftrag.
Die Arbeit unterstützt den vereinbarten Teil Ihrer CRA-Umsetzung. Sie ersetzt weder die rechtliche Einordnung Ihrer Produkte noch die vollständige Konformitätsbewertung oder den laufenden Umgang mit Schwachstellen.
CRA-Anforderungen und Fristen einordnen
Der CRA betrifft Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Nicht jede intern entwickelte Anwendung fällt darunter. Produktgrenzen und Herstellerverantwortung sind vor der Umsetzung zu klären.
Anhang I Teil II und Anhang VII der Verordnung (EU) 2024/2847 betreffen unter anderem Komponenten- und Schwachstellendokumentation mit einer maschinenlesbaren SBOM, Sicherheitsprüfungen und technische Dokumentation. Eine interne Freigabe oder Risikoakzeptanz hebt geltende gesetzliche Anforderungen nicht auf.
Die Hersteller-Meldepflichten gelten seit dem 11. September 2026 für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle mit Auswirkungen auf die Produktsicherheit. Ein CVE-Treffer allein löst keine Meldepflicht aus. Die übrigen Hauptpflichten gelten ab dem 11. Dezember 2027. Quellen: Meldepflichten und CRA-Überblick der EU-Kommission.
Was passiert, wenn ein Pflichtnachweis fehlt?
Die Freigaberegel prüft die vereinbarten Nachweise für das auszuliefernde Artefakt. Fehlt ein Pflichtnachweis, stoppt der reguläre Release-Weg. Eine Ausnahme braucht ein ausdrücklich vorgesehenes Verfahren und die zuständige Genehmigung.
Artefakt A
Pflichtprüfungen für A
- Ein Ergebnis liegt vor
- Ein weiteres fehlt
Freigaberegel
Stop
Pflichtnachweis fehlt
Freigabe
Erst wenn die Regel erfüllt ist
Ausnahme nur, wenn vorgesehen und ausdrücklich genehmigt.
Tests für A geben B nicht frei.
Illustratives Beispiel: Eine EU-Bank ändert die Berechnung von Kontoführungsentgelten. Softwarepaket A besteht die vereinbarten Tests. Für die Auslieferung entsteht beim Neubau jedoch ein anderes Paket B. Gehören die Ergebnisse noch zur ausgelieferten Software?
Vorher
Geprüft: A. Ausgeliefert: B.
Artefakt A
Tests bestanden
Neubau
Artefakt B
Ausgeliefert
Die Zuordnung der Prüfergebnisse bleibt ungeprüft.
Nachher
Die Regel stoppt Artefakt B.
Ergebnis für A
Gilt nicht für B
Zuordnung
Artefakt B
Zur Freigabe
Freigabe gestoppt. Kein Pflichtnachweis für B.
Fortsetzung nur mit passendem Ergebnis oder einer zulässigen, ausdrücklich genehmigten Ausnahme.
Die Umsetzung: Der Release-Schritt prüft, ob die erforderlichen Ergebnisse zum auszuliefernden Artefakt gehören.
Die Regel macht die vereinbarte Prüfung verbindlich. Wie aussagekräftig sie ist, hängt weiterhin davon ab, was sie tatsächlich testet.
Wer verantwortet welche Entscheidung?
Ein Release kann Abrechnung, Betriebsfähigkeit oder Kundendaten verändern. Fachlich und technisch Verantwortliche müssen deshalb gemeinsam klären, was richtig funktionieren soll, welche Risiken die Prüfungen abdecken und wer entscheiden darf.
Im Three Lines Model gehört diese Verantwortung zur First Line: Die Verantwortlichen in Fachbereich und IT steuern die Risiken ihrer Arbeit und betreiben die zugehörigen Kontrollen. Die Second Line gibt den Rahmen vor und überwacht und hinterfragt dessen Umsetzung. Internal Audit prüft als Third Line unabhängig. Eine unabhängige Freigabe innerhalb der First Line ist deshalb nicht automatisch eine Freigabe durch die Second Line.
- Anforderungen vereinbaren
- Die fachlich und technisch Zuständigen legen erwartete Ergebnisse und Prüfkriterien fest. Werden Anforderungen während der Umsetzung präzisiert, klären sie auch, welche Prüfungen oder Entscheidungen erneut nötig sind.
- Business Sign-off
- Die Fachseite legt die Abnahmekriterien fest. Daraus abgeleitete Tests prüfen wiederkehrende Fälle automatisch. Wo eine fachliche Abnahme je Änderung erforderlich ist, bestätigt die zuständige Person, dass die vereinbarten Anforderungen erfüllt sind.
- Release Readiness prüfen
- Automatisierte Checks prüfen, ob die vereinbarten Nachweise vollständig sind und zum Release gehören. Offene Abhängigkeiten, Betriebsübergabe und der Plan für Fehlerfälle werden nach klaren Kriterien bewertet. Klärungsbedarf geht gezielt an die zuständige Rolle.
- Release Approval
- Die vereinbarten Regeln bestimmen, wann eine Freigabe automatisiert erfolgen darf und wann eine befugte Person entscheiden muss. Wartungsfenster oder fachliche Starttermine bleiben dabei verbindlich.
Segregation of Duties (SoD) braucht mehr als zwei Benutzerkonten. Ich kläre mit Ihnen, welche Tätigkeiten unabhängig voneinander bleiben müssen, und setze die vereinbarte Trennung in Berechtigungen und Freigaberegeln um. Maßgeblich sind die tatsächlichen Aufgaben und Befugnisse der Beteiligten.
Was macht eine Kontrolle wirksam?
Am Anfang steht ein konkretes Risiko: etwa eine falsche Abrechnung oder eine ungeprüfte Änderung im Betrieb. Daraus leite ich mit Ihnen das Kontrollziel ab und lege fest, welche Änderungen die Kontrolle erfassen muss, wer sie verantwortet und welche Ergebnisse eine Freigabe erlauben.
Dann setze ich die Regel in Ihren Systemen um. Dazu gehört auch, wer Pflichtprüfungen verändern, Freigaberegeln bearbeiten oder einen Sonderweg nutzen darf. Die Zuständigkeit für Pflege und Überprüfung bleibt nach der Übergabe benannt.
Ich erprobe mit Ihrem Team auch, ob die Kontrolle im Fehlerfall greift. Im vereinbarten Umfang prüfe ich beispielsweise, ob ein fehlender Test den regulären Release-Weg stoppt, ob eine Freigabe für Artefakt A bei Artefakt B abgewiesen wird und ob eine abgelaufene Ausnahme ihre Wirkung verliert.
Wenn Ihr Unternehmen auf eine Release Control angewiesen ist, um ein wesentliches Risiko zu begrenzen, kann sie eine Key Control sein oder Teil davon. Das hängt von Ihrer Risikobewertung, Kontrollmethodik und anderen vorhandenen Kontrollen ab. Eine erfolgreiche Erprobung belegt noch nicht die dauerhafte Wirksamkeit im laufenden Betrieb.
Wie bleiben Ausnahmen und Emergency Changes kontrolliert?
Eine zulässige Ausnahme braucht einen Grund, einen befugten Genehmiger, einen begrenzten Geltungsbereich und ein Ablaufdatum. Gemeinsam legen wir fest, welche Abweichungen überhaupt zulässig sind, wer das verbleibende Risiko akzeptieren darf und welche Maßnahmen bis zur Behebung gelten.
Für Emergency Changes gestalte ich mit Ihnen einen eigenen Ablauf für dringende Änderungen: Wer bestätigt die Dringlichkeit? Welche Mindestprüfungen bleiben verbindlich? Was darf nachgeholt werden, durch wen und bis wann? Offene Nacharbeiten erhalten eine Zuständigkeit und einen Eskalationsweg.
Auch Rücknahme oder Korrektur, Prüfung nach dem Deployment und Übergabe an den Betrieb gehören in diesen Ablauf. Eine nachträgliche Genehmigung ersetzt keine fehlende Fehlerbehebung. Fristen und Befugnisse richten sich nach Ihren Anforderungen und Risiken.
Woran erkennen Sie, dass die Kontrolle ausgeführt wurde?
Für einen Release muss sich rekonstruieren lassen, welche Anforderungen und Regeln galten, welches Artefakt geprüft wurde, welche Ergebnisse vorlagen, wie die Freigabe zustande kam und was tatsächlich ausgeliefert wurde. Ich automatisiere die Verknüpfung der Prüfungen und Entscheidungen mit ihrer Quelle, ihrem Zeitpunkt und dem jeweiligen Release. So liegen die Nachweise für die Freigabe bereits vor, statt jedes Mal manuell zusammengesucht zu werden.
Ich kläre mit Ihnen auch, wie Sie die erfassten Änderungen mit den tatsächlichen Deployments abgleichen können. Vollständige Nachweise für einzelne Releases sagen noch nicht, ob alle Auslieferungen den vorgesehenen Weg genommen haben. Ein Abgleich kann Änderungen ohne zugehörigen Freigabedatensatz sichtbar machen.
Die Ausführung je Änderung, die regelmäßige Überwachung und die Überprüfung des Control Designs haben unterschiedliche Aufgaben. Ich lege mit Ihren Verantwortlichen fest, welche Nachweise jeweils gebraucht werden und wer Abweichungen bearbeitet. So erhält auch die unabhängige Überwachung eine nachvollziehbare Grundlage.
EU- und deutsche Grundlagen
EU-Finanzsektor: Für Banken im Anwendungsbereich von DORA verankert Artikel 5 der Verordnung (EU) 2022/2554 die Verantwortung für IKT-Risiken beim Leitungsorgan. Artikel 6 Absatz 4 adressiert die Unabhängigkeit der Risiko-, Kontroll- und Revisionsfunktionen. Artikel 9 Absatz 4 Buchstabe e verlangt ein risikobasiertes, kontrolliertes Change Management.
Entwicklung und Freigabe: Artikel 16 der Delegierten Verordnung (EU) 2024/1774 konkretisiert Anforderungen und deren Genehmigung durch die zuständige Geschäftsfunktion und den ICT Asset Owner sowie risikogerechte Tests. Artikel 17 Absatz 1 Buchstabe b verlangt die Unabhängigkeit der genehmigenden Funktionen von den Funktionen, die Änderungen beantragen und umsetzen. Die Buchstaben e bis g betreffen Fallback-Verfahren und Emergency Changes einschließlich nachträglicher Bewertung und Genehmigung.
Deutsche Unternehmen und öffentliche Einrichtungen: Der BSI-IT-Grundschutz-Baustein OPS.1.1.6, insbesondere A3 und A4 beschreibt die Auswertung von Testergebnissen und die dokumentierte Freigabe durch die fachlich zuständige Organisationseinheit. Er bietet einen deutschen Maßstab für die Gestaltung solcher Kontrollen; IT-Grundschutz ist keine pauschal geltende gesetzliche Pflicht.
Welche Anforderungen für Ihr Unternehmen gelten, ist vor der Umsetzung zu klären. Eine einzelne Freigaberegel ersetzt weder den gesamten Kontrollrahmen noch den Nachweis seiner Wirksamkeit. rebaze gestaltet und implementiert die vereinbarten Kontrollen; Rechtsberatung und ein unabhängiges Audit sind nicht Teil dieser Leistung.
Welche Lücke sollen Ihre Release Controls schließen?
Ich wähle mit Ihrem Team ein Produkt und einen Release-Weg, setze die vereinbarten Checks und Freigaberegeln in Ihren Systemen um und prüfe sie am nächsten Release. Ihr Team erhält Implementierung und Anleitung.
Umfang, Voraussetzungen, Dauer und Festpreis vereinbaren wir vor dem Auftrag.
Ihren Fall besprechen30 Minuten mit Toni Menzel. Kostenlos und unverbindlich.