S•U•S•I - Qualitätsmanagement für immoSoR

Rot-Kritisch · Schutzverletzung

Rot-Kritisch bezeichnet eine Verletzung zwingender Schutzbedingungen. Der Befund betrifft nicht nur Komfort oder Erreichbarkeit, sondern die Integrität des Systems.

Ein mögliches Risiko besteht insbesondere für Mandantentrennung, Rollenbindung, Datenscope, sichere Sitzung, wirtschaftliche Neutralität oder zulässige Außenwirkung.

Typische Ursachen sind:

• Mandantenvermischung,
• Zugriff auf fremde Daten,
• fehlende Rollenbindung,
• Rechtevereinigung nach einem Kontextwechsel,
• fehlende Capability-Prüfung,
• unzulässiger Object-, Referral- oder Own-Scope,
• manipulierte Sitzung,
• unklarer Impersonation-Zustand,
• nicht bestätigte Wirtschaftssperre,
• reale Wirkung statt Neutraltest,
• unkontrollierte Produktivfreigabe.

Eine Mandantenvermischung liegt beispielsweise vor, wenn ein Makler aus Unternehmen A ein Objekt aus Unternehmen B öffnen kann, ein Empfehlungspartner eine fremde Empfehlung sieht oder eine Assistenz einen nicht zugewiesenen Vorgang erreicht.

Auch ein Super-Admin darf Mandantendaten nicht ohne ausdrücklich gewählten und auditierten Kontext verändern. In diesen Fällen ist nicht nur eine einzelne Funktion fehlerhaft. Die zentrale Daten- und Berechtigungsgrenze ist verletzt.

Gleiches gilt bei einer verletzten Wirtschaftssperre. Verwendet der Neutraltest einen Wert ungleich 0,00 EUR, erzeugt ein Prüflauf eine Provision, verändert ein Guthaben oder bereitet eine Auszahlung beziehungsweise Rechnung vor, liegt ein kritischer Schutzbefund vor.

Auch wenn noch keine tatsächliche Geldbewegung erfolgt ist, reicht bereits eine nicht bestätigte Sperre aus. Der Wirtschaftsmodus muss durchgehend LOCKED bleiben.

Bei Rot-Kritisch wird die betroffene Funktion sofort Fail-Closed gesperrt. Die Sperre soll so präzise wie möglich wirken, damit unbetroffene Arbeitsbereiche grundsätzlich nutzbar bleiben.

Zusätzlich werden der Befund gesichert, die technische Verantwortung informiert, Audit- und Korrelationsdaten gebunden, mögliche Daten- oder Außenwirkungen geprüft und gegebenenfalls eine Reconciliation vorbereitet.

Eine einfache Wiederholung des Laufs genügt nicht. Vor einer erneuten Freigabe muss die Schutzursache vollständig geklärt und durch positive sowie negative Tests nachgewiesen werden.

Die Sperre richtet sich gegen eine unsichere Funktion und nicht gegen den Menschen. Auch wenn ein Nutzer den Befund sichtbar gemacht hat, bleibt die Ursache systemisch.

Die Stellungnahme lautet daher beispielsweise:

Die Mandantenbindung der betroffenen Funktion konnte nicht bestätigt werden.

Nicht:

Der Nutzer hat falsch gearbeitet.

Rot-Technisch · Funktions- oder Serviceausfall

Rot-Technisch bezeichnet eine Funktion, die aufgrund eines technischen Fehlers nicht ordnungsgemäß arbeitet. Die Schutzgrenzen können weiterhin intakt sein, während Dienst, Route, Controller, Datenbank oder eine technische Abhängigkeit ausfallen.

Typische Ursachen sind:

• HTTP 500,
• Timeout,
• nicht erreichbarer Service,
• Datenbankverbindungsfehler,
• Queue- oder Worker-Ausfall,
• ungültige Serverantwort,
• fehlende Route,
• Controllerfehler,
• fehlerhafter JSON-Vertrag,
• Asset- oder JavaScript-Ausfall,
• Cache- oder Versionskonflikt,
• abgebrochener Render- oder Hintergrundprozess.

Liefert der Server trotz gültigem Mandanten-, Rollen- und Scope-Kontext einen internen Fehler, lautet der Befund Rot-Technisch. Es handelt sich nicht automatisch um Rot-Kritisch, solange keine fremden Daten offengelegt, keine Schutzgrenze verletzt und keine wirtschaftliche Wirkung ausgelöst wurde.

Auch ein Timeout gehört in diese Kategorie. Antwortet ein Dienst nicht innerhalb der vorgesehenen Zeit, wird der Lauf kontrolliert beendet. Der erreichte Zwischenstand bleibt nachvollziehbar, und der Nutzer darf nicht in einem endlosen Ladezustand verbleiben.

Die technische Maßnahme besteht in Fehleranalyse, Klassifikation und Prüfung von Logs, Route, Service, Datenbank und Abhängigkeiten. Soweit gefahrlos möglich, kann ein kontrollierter Retry, eine Wiederaufnahme oder ein erneuter Funktionstest erfolgen.

Bei wiederkehrenden Fehlern können ein Prüfauftrag, ein vollständiges Rollen-Audit oder ein Reparaturpatch vorbereitet werden. Wiederholungen bleiben begrenzt. Retry, Backoff und Dead-Letter-Logik müssen definiert sein.

S•U•S•I erklärt den Befund verständlich. Statt einer Meldung wie Unhandled Exception im Service Layer kann die Stellungnahme lauten:

Der Rückrufdienst konnte technisch nicht abgeschlossen werden. Ihre übrigen Arbeitsbereiche bleiben verfügbar. Eine technische Nachprüfung wurde vorbereitet.

Rot-Nachweis · Audit- oder Quittierungslücke

Rot-Nachweis bedeutet, dass die Funktion technisch gearbeitet hat, der erforderliche Beleg jedoch fehlt oder unvollständig ist. Der fachliche Vorgang kann erfolgreich gewesen sein, revisionsseitig ist er aber nicht belastbar abgeschlossen.

Nachweisbarkeit ist im S•U•S•I-QM Bestandteil der Funktion und keine nachträgliche Dekoration.

Typische Nachweislücken sind:

• kein Auditereignis,
• keine Quittung,
• keine Run-ID-Verknüpfung,
• fehlender Nachweis-Hash,
• fehlende PDF,
• Widerspruch zwischen PDF und Datenbank,
• fehlender Arbeitsprotokolleintrag,
• fehlende Neutralitätsbestätigung,
• fehlender Versionsbezug,
• nicht korrelierbares Ereignis,
• nicht revisionsfähig dokumentierter Abschlussstatus.

Wurde der Tagescheck abgeschlossen, die Stellungnahme angezeigt und eine PDF erzeugt, der Hash jedoch nicht gebildet oder gespeichert, ist die technische Funktion nicht zwingend ausgefallen. Der revisionsfähige Abschluss fehlt dennoch. Der Befund lautet Rot-Nachweis.

Gleiches gilt, wenn ein Prüfauftrag ausgeführt wurde und das Soll-Ist-Ergebnis stimmt, aber kein vollständiges Auditereignis mit Akteur, Kontext, Zeit, Referenz und Ergebnis vorliegt. Der Vorgang kann später nicht zuverlässig rekonstruiert werden.

Bei Rot-Nachweis wird die fachliche Funktion nicht automatisch erneut ausgeführt. Zunächst wird geprüft, ob die fehlende Spur sicher rekonstruiert werden kann.

Mögliche Maßnahmen sind:

• Auditspur reparieren,
• Quittung nacherzeugen,
• Hash neu bilden,
• PDF-Verknüpfung korrigieren,
• Arbeitsprotokolleintrag ergänzen,
• Revisionsprüfung durchführen.

Eine Rekonstruktion darf keine erfundenen oder rückdatierten Daten erzeugen. Kann die Spur nicht zuverlässig wiederhergestellt werden, entsteht eine neue transparente Prüf- oder Nachweisrevision.

Rot-Nachweis bedeutet nicht automatisch, dass die fachliche Funktion unsicher ist. Die weitere Nutzung kann abhängig vom Pflichtgrad möglich bleiben.

Bei kritischen freigabe- oder wirtschaftsnahen Funktionen kann die Nutzung jedoch bis zur vollständigen Quittierung begrenzt bleiben. S•U•S•I muss deshalb klar unterscheiden:

Die Funktion arbeitet. Die Nachweisschicht fehlt.

Rot-Konfiguration · Pflichtkomponente oder Zuordnung fehlt

Rot-Konfiguration bezeichnet eine fehlende oder widersprüchliche Einrichtung. Die technische Plattform kann grundsätzlich funktionieren, während für den aktuellen Nutzer-, Rollen- oder Mandantenkontext eine erforderliche Voraussetzung fehlt.

Der Fehler liegt nicht zwingend im Code. Häufig fehlt eine Zuordnung, ein Profil, ein Funktionsregister oder eine notwendige Pflichtkomponente.

Typische Ursachen sind:

• keine aktive Rollenbindung,
• fehlende company_id,
• keine gültige Assistenzzuweisung,
• fehlendes Funktionsregister,
• fehlendes Policy-Profil,
• nicht zugewiesene Capability,
• nicht eingerichteter Pflichtservice,
• fehlender Dashboard-Anker,
• nicht konfigurierte Benachrichtigung,
• fehlende Objekt- oder Referral-Zuordnung,
• unvollständiger Mandantenkontext,
• falsche App- oder Registerversion.

Ist eine Assistenz korrekt angemeldet und der Aufgabenbereich technisch erreichbar, liegt aber keine gültige Zuweisung vor, kann die Funktion fachlich nicht korrekt geöffnet werden. Der Befund lautet Rot-Konfiguration.

Auch beim Makler-Leitstand kann die Route vorhanden und der Controller erreichbar sein, während das erforderliche Funktionsprofil oder die Mandantenzuordnung fehlt. Eine technische Wiederholung ohne vorherige Einrichtung würde nichts ändern.

Die Maßnahme besteht darin, die fehlende Einrichtung im richtigen Kontext nachzuholen. Dazu können Rollen-, Capability-, Objekt-, Vorgangs- oder Profilzuweisungen, die Vervollständigung des Funktionsregisters, die Konfiguration eines Dienstes oder die korrekte Versionsbindung gehören.

Jede Änderung benötigt einen berechtigten Akteur, einen nachvollziehbaren Grund, Vorzustand, Ergebnis und Auditspur.

Berechtigungs- und rollenrelevante Einstellungen dürfen nicht automatisch selbst repariert werden. Nach der Einrichtung wird gezielt neu geprüft.

Rot-Konfiguration darf außerdem nicht durch pauschale Rechteerweiterung „behoben“ werden. Eine fehlende Capability rechtfertigt weder eine globale Rolle noch Super-Admin-Rechte oder einen erweiterten Mandantenscope.

Die Korrektur muss minimal, fachlich passend und sicher sein.

Abgrenzung der vier Kategorien

Rot-Kritisch bedeutet: Eine Schutzgrenze ist verletzt, ein Daten-, Rollen- oder Wirtschaftsrisiko ist möglich, und die betroffene Funktion muss sofort gesperrt sowie eskaliert werden.

Rot-Technisch bedeutet: Eine Funktion oder ein Dienst ist ausgefallen, während die Schutzgrenzen weiterhin intakt sein können. Es folgen Fehleranalyse und kontrollierte Wiederholung.

Ein HTTP-500-Fehler ist daher nicht automatisch kritisch. Eine Mandantenvermischung ist dagegen nicht nur technisch.

Rot-Nachweis bedeutet: Die Funktion wurde ausgeführt, aber Audit, Quittung oder Hash fehlen.

Rot-Konfiguration bedeutet: Die Funktion kann nicht korrekt ausgeführt werden, weil eine notwendige Einrichtung oder Zuordnung fehlt.

Beim Nachweisproblem wird die Spur repariert. Beim Konfigurationsproblem wird der Arbeitskontext eingerichtet.

Mehrere Kategorien können gleichzeitig auftreten

Ein Vorgang kann mehrere Befunde besitzen, etwa einen Serviceausfall und zusätzlich eine fehlende Quittierung.

Die Befunde werden getrennt gespeichert. Der Gesamtstatus richtet sich nach der höchsten Schutzrelevanz. Rot-Kritisch hat Vorrang vor den anderen Kategorien.

Die Maßnahmen bleiben dennoch je Ursache getrennt. Ein Sammelstatus ohne Einzelbefunde wäre nicht ausreichend.

Der Neutraltest schützt auch bei Rot

Sämtliche Audit- und Tagesläufe arbeiten weiterhin mit 0,00 EUR. Ein roter Befund bedeutet nicht automatisch, dass Geld oder Vermögen betroffen sind.

Auch bei Rot-Technisch, Rot-Nachweis oder Rot-Konfiguration entstehen keine Forderung, Provision, Auszahlung, Kundenbuchung oder wirtschaftliche Anerkennung.

Der Wirtschaftsmodus bleibt LOCKED.

Häufig betrifft ein roter Befund ausschließlich technische Ausführung, Nachweisschicht oder Einrichtung. Diese Klarstellung verhindert unnötige wirtschaftliche Alarmierung.

Rot und die weitere Systemnutzung

Nicht jeder rote Befund sperrt den gesamten Arbeitsraum. Die Reaktion bleibt auf die betroffene Funktion begrenzt.

Ein fehlender PDF-Hash kann die Nachweisschicht auf Rot setzen, während eine Lesesicht weiterhin nutzbar bleibt. Ein HTTP-500-Fehler im Rückrufdienst betrifft die Rückruffunktion, nicht automatisch die Objektübersicht. Eine fehlende Assistenzzuweisung blockiert den zugewiesenen Arbeitsbereich. Eine Mandantenvermischung führt dagegen zur sofortigen Sperre der betroffenen Funktion.

S•U•S•I benennt ausdrücklich, welche Bereiche weiterhin genutzt werden können.

Ursache, Wirkung und Maßnahme gehören zusammen

Jeder rote Befund benötigt mindestens:

• Kategorie,
• Funktionsbezug,
• Klartextursache,
• betroffenen Kontext,
• praktische Auswirkung,
• Risiko,
• Sofortmaßnahme,
• zuständige Stelle,
• nächste Prüfung,
• Run-ID und Nachweis.

Rot ohne Maßnahme ist keine vollständige Diagnose. Eine Maßnahme ohne dokumentierte Ursache ist nicht revisionsfähig.

S•U•S•I-Stellungnahmen nach Kategorie

Rot-Kritisch:

Die Mandantenbindung der betroffenen Funktion konnte nicht bestätigt werden. Die Funktion wurde vorsorglich gesperrt. Andere geprüfte Arbeitsbereiche bleiben verfügbar. Eine technische Sicherheitsprüfung wurde sofort eingeleitet.

Rot-Technisch:

Der Dienst konnte den Vorgang aufgrund eines technischen Fehlers nicht abschließen. Es entstand keine wirtschaftliche Wirkung. Eine kontrollierte Wiederholung und Fehleranalyse wurden vorbereitet.

Rot-Nachweis:

Die Funktion wurde technisch abgeschlossen, die vollständige Audit- und Hashbindung konnte jedoch nicht bestätigt werden. Die Nachweisschicht wird geprüft und revisionsfähig ergänzt.

Rot-Konfiguration:

Die Funktion ist technisch vorhanden, für den aktuellen Rollen- und Mandantenkontext fehlt jedoch eine erforderliche Zuordnung. Die Einrichtung muss durch eine berechtigte Stelle vervollständigt werden.

Übergabe an Folgemaßnahmen

Rot-Kritisch führt zu Incident, Sperre, Reconciliation und Sicherheitsprüfung.

Rot-Technisch führt zu Fehleranalyse, Retry, Agenten- oder Workerprüfung und gegebenenfalls Reparaturpatch.

Rot-Nachweis führt zu Auditprüfung, Quittungsreparatur sowie Hash- und PDF-Abgleich.

Rot-Konfiguration führt zu Einrichtungsauftrag, Rollen- oder Capability-Prüfung und erneutem Kontextcheck.

Der technische Agent darf Prüfaufträge erzeugen. Er darf jedoch keine ungeprüfte fachliche oder wirtschaftliche Freigabe vornehmen.

Revision und Historie

Ein später behobener roter Befund wird nicht gelöscht. Die Historie enthält ursprünglichen Befund, Kategorie, Ursache, Maßnahme, Reparatur, erneuten Test und neues Ergebnis.

Eine Korrektur erzeugt ein neues Ereignis oder eine neue Revision. Dadurch bleibt nachvollziehbar, wann und wie die Funktion wieder in einen sicheren und nachgewiesenen Zustand überführt wurde.