Enterprise Security · Datensicherheit · Betriebssicherheit
Sicherheit ist bei uns keine Checkbox.
PPWR-Ready ist als mehrmandantenfähige Compliance-Plattform gebaut — mit getrennten Unternehmensdaten, nachvollziehbaren Änderungen, kontrollierter Geschäftslogik und geprüften Sicherheits- und Wiederherstellungsmechanismen.
Diese Seite erklärt, wie das technisch funktioniert. Jede Zahl darauf stammt aus einer Messung am laufenden System, nicht aus einer Broschüre. Wo etwas offen ist, steht das ebenfalls hier.
Stand dieser Seite: 21. September 2026. Die technischen Angaben werden bei jeder Sicherheitsprüfung neu gegen das laufende System abgeglichen.
Einordnung
KI kann unterstützen. Sie ist nicht die Quelle der Wahrheit.
Ob eine Verpackung eine Anforderung erfüllt, ob ein Nachweis gültig ist, ob eine Umweltaussage getragen wird — diese Fragen beantwortet PPWR-Ready nicht mit einem Sprachmodell. Sie werden aus strukturierten Daten und fest hinterlegten Regeln abgeleitet.
Regulatorisch entscheidend
Anforderungskatalog mit Fundstelle · deterministische Regeln in der Datenbank · definierte Zustände · verknüpfte Nachweise · Versionierung · Änderungshistorie
Unterstützend, nie entscheidend
Vorschläge beim Erfassen · Auslesen von Katalogen und Dokumenten · Textentwürfe · Einordnungshilfen. Was dabei herauskommt, ist ein Vorschlag, den ein Mensch prüft.
Wir behaupten nicht, dass wir keine KI einsetzen. Wir sagen, wo sie steht: außerhalb der Kette, an deren Ende eine Compliance-Entscheidung hängt.
Vier Ebenen, die oft verwechselt werden
„Ist das sicher?" meint je nach Gesprächspartner etwas anderes. Wir trennen die vier Fragen, weil sie verschiedene Antworten haben.
Datenschutz
Wer darf welche personenbezogenen Daten zu welchem Zweck verarbeiten? Das regeln Auftragsverarbeitungsvertrag, technisch-organisatorische Maßnahmen und die Liste der Unterauftragsverarbeiter — alle drei sind öffentlich abrufbar.
Datensicherheit
Wie werden Daten vor unberechtigtem Zugriff und unberechtigter Veränderung geschützt? Durch Mandantentrennung auf Datenbankebene, serverseitige Berechtigungsprüfung und sparsam vergebene Rechte.
Betriebssicherheit
Was passiert bei Last, Fehlern, gleichzeitigen Zugriffen oder einem Ausfall? Dazu gehören Sperren gegen Wettlaufsituationen, Ratengrenzen, kontrollierte Fehlerbehandlung, Sicherungen und eine wöchentliche Wiederherstellungsprobe.
Nachvollziehbarkeit
Lässt sich rekonstruieren, was geändert wurde und auf welcher Grundlage eine Entscheidung entstand? Änderungen, Dokumentfassungen, Bewertungen und Freigaben werden mit Zeitpunkt, Person und Begründung festgehalten.
Wo die Grenzen liegen
Eine Anfrage durchläuft mehrere Kontrollen, bevor sie Daten sieht oder verändert. Entscheidend ist: keine dieser Kontrollen sitzt allein im Browser.
1 · Eingang
Benutzer oder angebundenes System
Oberfläche, Schnittstelle oder Plugin. Alles, was von hier kommt, gilt als ungeprüft.
2 · Identität
Anmeldung und Berechtigung
Wer ist das, und was darf diese Person? Die Antwort entsteht auf dem Server, nicht im Anstrich.
3 · Mandantengrenze
Zeilenschutz in der Datenbank
Jede Zeile gehört zu einem Konto. Die Datenbank gibt nur Zeilen heraus, die zum Konto der Anfrage passen — unabhängig davon, was die Anwendung fragt.
4 · Fachlogik
Regeln, Prüfungen und Zustände
Anforderungskatalog, Bewertungslogik und erlaubte Zustandsübergänge. Ein Zustand lässt sich nicht durch einen Aufruf von außen setzen.
5 · Schreiben
Transaktionen, Bedingungen, Sperren
Fremdschlüssel, Prüfbedingungen und Sperren gegen gleichzeitige Zugriffe. Entweder eine Änderung gilt ganz, oder sie gilt nicht.
6 · Gedächtnis
Historie, Fassungen, Nachweise
Was geändert wurde, wer es geändert hat und welche Dokumentfassung einer Entscheidung zugrunde lag.
Quer zu allen Ebenen
Überwachung · Ratengrenzen · Fehlerbehandlung mit Vorgangskennung · Sicherung und Wiederherstellung. Integrationen und Automatisierung laufen außerhalb dieser Kette und erhalten keine Sonderrechte an der Mandantengrenze.
Jedes Unternehmen sieht nur seine eigenen Daten.
PPWR-Ready ist mehrmandantenfähig: alle Kunden arbeiten auf derselben Anwendung, aber auf getrennten Daten. Die Trennung ist keine Filterfunktion in der Oberfläche. Sie wird von der Datenbank selbst durchgesetzt, über Zeilenschutz (Row Level Security).
Der Unterschied ist praktisch bedeutsam: Wenn eine Abfrage einen Filter vergisst, liefert die Datenbank trotzdem nur die eigenen Zeilen. Die Grenze hängt nicht davon ab, dass jede einzelne Abfrage korrekt geschrieben ist.
Gemessen am 21.09.2026
Sieben Tabellen tragen Zeilenschutz ohne jede Richtlinie. Das ist Absicht und der engste mögliche Zustand: dort sieht niemand außer dem Dienstkonto eine Zeile. Jede dieser Tabellen trägt einen Vermerk, damit niemand den vermeintlichen Mangel „behebt" und sie damit öffnet.
Ein ausgeblendeter Knopf ist keine Sicherheitskontrolle
Berechtigungen werden dort geprüft, wo die Daten liegen. Was die Oberfläche anzeigt oder verbirgt, ist eine Frage der Bedienbarkeit — nicht der Sicherheit. Wer eine Schnittstelle direkt anspricht, trifft auf dieselben Kontrollen.
Rechte werden sparsam vergeben: Benutzer erhalten, was ihre Rolle braucht; technische Funktionen erhalten genau die Rechte für ihre Aufgabe und sonst keine.
Ein Beispiel aus einer echten Prüfung
Bei einer Sicherheitsdurchsicht fiel auf, dass sämtliche Trigger-Funktionen über die öffentliche Schnittstelle direkt aufrufbar waren — eine Standardeinstellung, kein Einbruch. Das Ausführungsrecht wurde entzogen; der Direktaufruf endet seitdem mit „nicht gefunden". Anschließend wurde nachgewiesen, dass die Trigger weiterhin auslösen: PostgreSQL prüft dieses Recht beim Anlegen des Triggers, nicht bei jedem Auslösen. Eine Härtung, die stillschweigend eine Funktion gebrochen hätte, wäre keine Verbesserung gewesen.
Eine Compliance-Entscheidung darf keine Black Box sein.
In einer Prüfung zählt nicht, dass ein Status grün ist. Es zählt, warum er grün ist, wann er es wurde und worauf er sich stützte. Deshalb führt PPWR-Ready für die tragenden Objekte eine Änderungshistorie: Artikel, Bauteile, Lieferanten, Dokumente und Dokumentfassungen, Bewertungen, Freigaben und Zustandsänderungen.
Was passiert, wenn sich etwas ändert
- Lieferant geändert
- →
- abhängige Nachweise erkannt
- →
- betroffene Prüfung markiert
- →
- erneute Bewertung
- →
- Änderung protokolliert
- →
- neue Entscheidung
Wichtig dabei: Die alte Entscheidung verschwindet nicht. Sie bleibt mit Person, Zeitpunkt und Begründung stehen — sie ist der Nachweis dafür, was damals auf welcher Grundlage entschieden wurde. Markiert wird die Bewertung als überholt, nicht die Entscheidung gelöscht.
Welche Fassung lag der Entscheidung zugrunde?
Ein Nachweis wird nicht überschrieben. Eine neue Datei wird eine neue Fassung; die vorherige bleibt mit ihrer Prüfung und ihrer Entscheidung erhalten. Prüfung und Freigabe hängen dabei an der Fassung, nicht am Dokument — sonst zeigte eine erteilte Freigabe nachträglich auf eine Datei, die niemand geprüft hat.
Ändert sich die Grundlage, wird eine freigegebene Fassung auf erneut zu prüfen gesetzt. Auslöser sind unter anderem: geänderte Bauteile, geänderte Gewichte, ein gewechselter Lieferant, ein geänderter Rezyklatanteil oder ein ersetzter beziehungsweise abgelaufener Nachweis.
Jede Fassung trägt zusätzlich eine Prüfsumme ihrer Datei. Damit lässt sich belegen, dass die Datei, die heute im Archiv liegt, dieselbe ist, die damals freigegeben wurde.
Betriebssicherheit
Nicht nur Einzeltests. Auch echte Gleichzeitigkeit.
Die meisten Fehler in Geschäftsanwendungen entstehen nicht bei einem Nutzer, sondern bei mehreren gleichzeitig. Das Muster ist fast immer dasselbe: lesen, entscheiden, schreiben — ohne Sperre dazwischen. Zwei gleichzeitige Vorgänge sehen beide den Stand vor dem jeweils anderen, und beide kommen durch.
Wir haben das nicht theoretisch geprüft, sondern mit echten parallelen Zugriffen gemessen. Fünf solcher Stellen wurden gefunden und behoben — jede mit einer Messung vorher und nachher.
Das Mittel richtet sich nach der Frage: Entscheidung über eine Zeile → Zeilensperre. Entscheidung über eine Menge → Sperre je Konto. Eindeutigkeit → eindeutiger Index. Eine tägliche Prüfung schlägt an, wenn eine dieser Sperren wieder verschwindet — denn kein Werkzeug im Bauprozess sieht in die Datenbank hinein.
Offen und hier genannt: Geprüft wurden die Artikelgrenze, Lieferanten, Bauteile, die Schnittstellengrenze und das Fehlerprotokoll. Dasselbe Muster steckt auch in Sitzplätzen, Länderregistrierungen und Guthaben — diese Pfade sind nicht gemessen.
Missbrauch begrenzen
Schnittstellenzugriffe sind mengenmäßig begrenzt. Schreibende Zugriffe ohne Anmeldung sind auf wenige, eigens dafür gebaute Wege beschränkt, die jeweils über ein Token oder eine nicht erratbare Kennung geschützt sind — etwa Lieferantenportale oder die öffentliche Nachweisprüfung. Die konkreten Schwellen veröffentlichen wir bewusst nicht.
Fehler kontrolliert behandeln
Ein Fehler zeigt dem Nutzer eine Vorgangskennung — eine kurze Zeichenfolge, die sich kopieren und an den Support geben lässt. Sie verweist auf den vollständigen technischen Eintrag, der intern liegt. Dadurch bekommt der Support alles, was er braucht, ohne dass die Fehlermeldung selbst interne Einzelheiten preisgibt.
Geheimnisse nicht durchreichen
Bevor eine Fehlermeldung gespeichert wird, wird sie gesäubert: Schlüssel, Token und ähnliche Zeichenfolgen werden entfernt, lange Stapelspuren gekürzt. Zugangsdaten, interne Adressen und Datenbankeinzelheiten erscheinen weder in Meldungen an den Nutzer noch in öffentlichen Ausgaben.
Datenintegrität
Beziehungen zwischen Objekten werden über Fremdschlüssel erzwungen, Wertebereiche über Prüfbedingungen, Eindeutigkeit über Indizes. Mehrteilige Vorgänge laufen in einer Transaktion: entweder gilt alles, oder nichts. Abgeleitete Werte werden in der Datenbank berechnet, nicht im Browser.
Sicherheit heißt auch: Was passiert, wenn etwas schiefgeht?
Eine Sicherung, die nie zurückgespielt wurde, ist keine Sicherung, sondern eine Hoffnung. Deshalb läuft wöchentlich eine Wiederherstellungsprobe — nicht nur ein Prüfen, ob die Datei existiert.
- Sicherung
- →
- vollständig zurückgeholt
- →
- in eine Wegwerf-Datenbank eingespielt
- →
- Kerntabellen tragen Zeilen
Der Befund, der die Probe geprägt hat
Eine absichtlich abgeschnittene Sicherung bestand die Inhaltsprüfung unverändert — das Inhaltsverzeichnis steht am Anfang der Datei und listete alle Einträge, obwohl die Daten fehlten. Erst die letzte Stufe fing sie: dieselbe Datei stellte Tabellen her, aber die Stammdatentabelle hatte null Zeilen. Wer die Zeilenzählung aus einer Wiederherstellungsprobe herausnimmt, nimmt ihr den Sinn.
Wir nennen hier bewusst keine Wiederherstellungszeit und keinen Wiederherstellungspunkt als Zahl. Die Wiederherstellbarkeit wird wöchentlich geprüft und in unserem Servicelevel zugesagt; eine belastbare Zeitgarantie ist damit nicht dasselbe und wäre erst nach einer vollständigen Übung seriös.
Sicherheit wird getestet — nicht nur behauptet.
Geprüft und dokumentiert wurden bisher: Mandantentrennung, Berechtigungen, Schnittstellensicherheit, Gleichzeitigkeit, Ratengrenzen, Änderungshistorie, Sicherung und Wiederherstellung sowie gezielte Angriffsproben auf die Fachlogik.
Laufende Prüfungen, Stand 21.09.2026
Warum „erfolgreich" nicht immer erfolgreich heißt
Über 2.000 geplante Läufe meldeten durchgehend „erfolgreich". Dieser Status sagt aber nur, dass der Auftrag abgesetzt wurde. In der Antworttabelle standen am selben Tag vier echte Zeitüberschreitungen, die spurlos verschwunden wären. Seitdem prüft ein eigener Wächter die Antworten, nicht die Aufträge. Eine Überwachung, die das Falsche misst, ist gefährlicher als gar keine — sie erzeugt Vertrauen ohne Deckung.
Ein Befund vom 21.09.2026 — gefunden und geschlossen
Bei einer Angriffsprobe gegen die Nachweisverknüpfung fiel auf, dass die Zugriffsregel nur die Dokumentseite prüfte: Sie stellte sicher, dass das Dokument dem eigenen Konto gehört — aber nicht, dass das Ziel es ebenfalls tut. Theoretisch hätte sich damit ein eigenes Dokument an ein fremdes Objekt hängen lassen. Die Lücke wurde noch am selben Tag für alle zehn Zielarten geschlossen, und zwar in der Datenbank selbst, damit sie auch dort greift, wo die Zugriffsregel umgangen werden könnte. Acht Proben bestätigen die Wirkung, einschließlich des nachträglichen Umbiegens einer bestehenden Verknüpfung. Zu diesem Zeitpunkt gab es im Dokumentenmodell noch keine Produktivdaten — es war also nichts zu reparieren, nur zu verhindern.
Automatisierung steht außerhalb der Entscheidungskette
PPWR-Ready nutzt eine Automatisierungsschicht für Abläufe, die um die Compliance herum stattfinden: Anbindungen an Shop- und Warensysteme, Benachrichtigungen, geplante Abläufe, Aufbereitung eingehender Dokumente.
Was dort nicht stattfindet: Berechtigungsentscheidungen, Mandantentrennung, regulatorische Bewertungen, Zustandsübergänge und Datenintegrität. Diese bleiben im kontrollierten Kern — in der Datenbank und den geprüften Regeln. Eine Automatisierung, die eine Compliance-Entscheidung fällen könnte, wäre eine zweite Wahrheit.
Prinzipien, nach denen gebaut wurde
Das sind Bauprinzipien, keine Zertifikate. Sie sind im System umgesetzt und oben im Einzelnen belegt.
Was wir nicht behaupten
Wer bei Sicherheit nur Stärken aufzählt, sagt nichts. Diese Punkte gehören zur ehrlichen Antwort dazu.
- Wir sind nicht nach ISO 27001, SOC 2, BSI-Grundschutz oder vergleichbaren Normen zertifiziert. Es gibt dafür kein unabhängiges Testat, und wir behaupten keines. Die Vorarbeiten dazu laufen getrennt und sind kein Ersatz für eine Zertifizierung.
- Es gibt bislang keinen externen Penetrationstest. Die beschriebenen Prüfungen haben wir selbst durchgeführt und dokumentiert. Das ist etwas anderes als eine unabhängige Prüfung durch Dritte.
- PPWR-Ready garantiert nicht die rechtliche Konformität Ihres Unternehmens. Die Software unterstützt regulatorische Prüfungen mit strukturierten Daten und belegten Anforderungen. Die rechtliche Verantwortung bleibt beim Unternehmen.
- Technische Sicherheit ersetzt keine organisatorische Sicherheit auf Ihrer Seite. Wer Zugangsdaten teilt oder ausgeschiedene Mitarbeiter nicht entfernt, hebt jede Mandantentrennung auf.
- Wir versprechen keine unbegrenzte Skalierbarkeit und keine Verfügbarkeitszahl, die nicht vertraglich hinterlegt ist. Was zugesagt ist, steht im Servicelevel — nicht auf dieser Seite.
- Kein System ist frei von Fehlern. Die Befunde auf dieser Seite sind echte Fehler, die wir in unserem eigenen System gefunden haben. Wir gehen davon aus, dass es weitere gibt, und suchen weiter.
Häufige Fragen zur Sicherheit
Sind meine Unternehmensdaten von denen anderer Kunden getrennt?
Ja. Jede Zeile in der Datenbank gehört zu genau einem Konto, und die Datenbank gibt nur Zeilen heraus, die zum Konto der anfragenden Person passen. Am 21.09.2026 war dieser Zeilenschutz auf allen 199 Tabellen des Anwendungsschemas aktiv, geregelt durch 225 Zugriffsrichtlinien. In der letzten Trennungsprobe sah ein zweites Konto unter echter Anmeldung keine einzige fremde Zeile.
Wie genau schützt PPWR-Ready die Mandantendaten?
Die Grenze wird auf Datenbankebene durchgesetzt, nicht in der Oberfläche. Das ist der entscheidende Unterschied: Selbst wenn eine Abfrage in der Anwendung einen Filter vergäße, lieferte die Datenbank weiterhin nur die eigenen Zeilen. Zusätzlich prüfen Wächter direkt an den Schreibwegen, dass ein Objekt und sein Nachweis zum selben Konto gehören — auch dort, wo der Zeilenschutz technisch umgangen werden könnte.
Verwendet PPWR-Ready KI für Compliance-Entscheidungen?
Nein. Prüfergebnisse entstehen aus strukturierten Daten und fest hinterlegten Regeln mit Fundstelle im Rechtstext. KI unterstützt beim Erfassen und Aufbereiten — etwa beim Auslesen eines Katalogs oder beim Entwurf eines Textes. Was dabei entsteht, ist ein Vorschlag, den ein Mensch prüft. Eine Freigabe trifft immer eine Person, mit Namen, Zeitpunkt und Pflichtbegründung.
Ist PPWR-Ready eine Black-Box-KI-Lösung?
Nein. Zu jedem Prüfergebnis lässt sich anzeigen, welche Anforderung es ausgelöst hat, welche Fundstelle dahintersteht, welcher Nachweis verknüpft ist und wann zuletzt geprüft wurde. Wo das System eine Frage nicht maschinell entscheiden kann, sagt es das ausdrücklich, statt ein Ergebnis zu erfinden.
Kann ich nachvollziehen, wie eine Compliance-Entscheidung entstanden ist?
Ja. Zu jeder Bewertung werden der Zustand, die Begründung im Klartext, die zugrunde liegende Anforderung mit Fundstelle und der Prüfzeitpunkt festgehalten. Ändert sich die Grundlage, wird die Bewertung als überholt markiert — die frühere Entscheidung bleibt mit Person, Zeitpunkt und Begründung erhalten.
Werden Änderungen und Dokumentfassungen gespeichert?
Ja. Dokumente werden nicht überschrieben: Eine neue Datei wird eine neue Fassung, die vorherige bleibt mit ihrer Prüfung erhalten. Jede Fassung trägt eine Prüfsumme ihrer Datei. Änderungen an Artikeln, Bauteilen, Lieferanten, Bewertungen und Freigaben werden in einer Historie festgehalten, die am 21.09.2026 24.363 Einträge umfasste.
Was passiert bei einem Systemfehler?
Der Fehler wird abgefangen und protokolliert, bevor er den Nutzer erreicht. Dieser sieht eine kurze Vorgangskennung zum Kopieren; der vollständige technische Eintrag bleibt intern. Vor dem Speichern wird die Meldung gesäubert, damit Schlüssel und Token nicht im Protokoll landen. Die Fehlermeldung selbst wirft nie einen eigenen Fehler — sonst verdeckte sie den ursprünglichen.
Wie wird Missbrauch verhindert?
Schnittstellenzugriffe sind mengenmäßig begrenzt, und die Begrenzung wurde unter echter Gleichzeitigkeit gemessen — eine frühere Fassung ließ bei einer Grenze von fünf zwölf von zwölf Anfragen durch. Schreibende Zugriffe ohne Anmeldung gibt es nur auf wenigen, eigens dafür gebauten Wegen, die jeweils über ein Token oder eine nicht erratbare Kennung geschützt sind. Konkrete Schwellen veröffentlichen wir nicht.
Wie testet PPWR-Ready seine Sicherheit?
Über eine Kombination aus Prüfungen im Bauprozess, gezielten Angriffsproben gegen die Fachlogik und Messungen am laufenden System. Zu jeder Prüfung gehört eine Gegenprobe: Ein absichtlich eingebauter Fehler muss den Wächter auslösen. Ein Wächter, der nichts finden kann, ist schlimmer als keiner — er erzeugt Vertrauen ohne Deckung.
Ist PPWR-Ready nach ISO 27001 oder SOC 2 zertifiziert?
Nein. Für diese Normen liegt kein unabhängiges Testat vor, und wir führen keines. Was wir stattdessen anbieten, sind nachprüfbare technische Angaben, ein Auftragsverarbeitungsvertrag, eine Beschreibung der technisch-organisatorischen Maßnahmen, eine Liste der Unterauftragsverarbeiter und ein Servicelevel. Für eine Lieferantenprüfung stellen wir die technischen Einzelheiten auf Anfrage bereit.
Wo liegen die Daten?
Die Datenverarbeitung, die eingesetzten Dienstleister und die Verarbeitungsorte sind in der Liste der Unterauftragsverarbeiter und in den technisch-organisatorischen Maßnahmen beschrieben. Beide Dokumente sind öffentlich abrufbar und Bestandteil des Auftragsverarbeitungsvertrags.
Unterlagen und weiterführende Seiten
Die rechtlichen und vertraglichen Unterlagen ergänzen diese technische Darstellung:
- Auftragsverarbeitungsvertrag — Zweck, Weisungsbindung, Pflichten
- Technisch-organisatorische Maßnahmen — Schutzmaßnahmen im Einzelnen
- Unterauftragsverarbeiter — welche Dienstleister beteiligt sind
- Servicelevel — was zugesagt ist, einschließlich der Wiederherstellbarkeit
- Datenschutzerklärung
Fachlich passend dazu:
- Produktcompliance in der EU — welche Regelwerke für welches Produkt greifen
- EmpCo-Richtlinie und Umweltaussagen — wie geprüfte Aussagen entstehen und belegt werden
- Schnittstelle und Anbindung — wie eigene Systeme und Assistenten angebunden werden
Prüfen Sie uns.
Für eine Lieferanten- oder IT-Sicherheitsprüfung stellen wir die technischen Einzelheiten auf Anfrage bereit. Wer zuerst das Produkt sehen möchte: Die kostenlose Prüfung zeigt ohne Anmeldung, welche Regelwerke Ihr Unternehmen betreffen.
Betroffenheit prüfen