C3 Compliance

Deutsche Compliance — DSGVO, NIS2, AI Act + 6 weitere

Erstellt von Rogue AI · Selbst gehostete mandantenfähige Compliance-App · Selbst gehostet · Lokales Labor

Allein in mehreren fokussierten Build-Sprints im Labor entstanden.

C3 Compliance — Deutsche Compliance — DSGVO, NIS2, AI Act + 6 weitere

Das Problem

Deutsche KMU stehen vor einem Stapel sich überlappender Compliance-Regime — DSGVO, NIS2, AI Act, KRITIS, ISO 27001, SOC 2, TISAX, BAIT, VAIT — und jedes wird meist als eigene Tabelle, eigener Berater und eigener Nachweisberg behandelt. Die Überschneidung ist enorm: Eine einzige technische Maßnahme erfüllt oft Pflichten aus mehreren Frameworks zugleich, doch nichts verknüpft sie, sodass dieselben Nachweise immer wieder neu zusammengetragen werden. C3 modelliert alle neun an einem Ort, bildet geteilte Kontrollen über sie hinweg ab und hält die Nachweise in einem prüfbaren System statt in neun getrennten.

Was ich gebaut habe

Eine mandantenfähige Next.js-16-Anwendung, in der eine Organisation Assessments gegen jedes der neun Frameworks über eine einzige generische Engine durchführen, Nachweise und Dokumente pro Framework anhängen und sehen kann, wo eine Kontrolle Pflichten in mehreren Regimen zugleich erfüllt. Die Authentifizierung ist ein eigenes jose-JWT in einem httpOnly-Cookie, das auch die aktive Organisation trägt, sodass jede Abfrage mandantenbezogen ist. Datensätze, die auditsicher sein müssen — Einwilligungs- und Kontrollprotokolle — sind nur einfügbar. Stripe ist für einen kostenpflichtigen Compliance-Bericht verdrahtet. Es läuft als drei gehärtete Docker-Container (App, PostgreSQL, Redis) in einem lokalen Labor; es steht keine verwaltete Cloud dahinter.

Architektur

Generische Assessment-Engine über neun Frameworks

Statt neun Codepfaden löst eine Engine die Fragen, Empfehlungen und das Speichermodell für das jeweils angeforderte Framework auf, geroutet über einen Framework-Slug. Ein Framework hinzuzufügen oder zu überarbeiten ist eine Datenänderung — ein neuer Frage- und Empfehlungssatz — kein neues Subsystem.

Mandantenbezogene Organisations-Trennung

Ein Organization-Modell plus ein Org-Umschalter in der Oberfläche, mit der aktiven Organisations-ID eingebettet im Session-JWT. Assessments, regulatorische Hinweise, Dokumente und Berichte sind alle pro Organisation isoliert, sodass kein Mandant die Daten eines anderen sieht.

Framework-übergreifendes Kontroll-Mapping

Weil jedes Framework gegen dasselbe Kontroll-Vokabular modelliert ist, lässt sich zeigen, dass eine einzige technische oder organisatorische Maßnahme zugleich Pflichten aus DSGVO, ISO 27001, NIS2 und weiteren erfüllt — der eigentliche Grund, sie zu vereinen statt neun getrennte Tracker zu führen.

Append-only-Nachweis- und Einwilligungsprotokoll

Einwilligungs- und Kontrolldatensätze sind nur einfügbar, sodass die Historie nicht nachträglich umgeschrieben werden kann. Das ist eine bewusste Unveränderlichkeits-Vorgabe in der Datenschicht, kein Funktionsschalter, und genau das macht die gesammelten Nachweise in einem Audit belastbar.

Eigene JWT-Authentifizierung mit Mandanten-Session-Kontext

Zustandsloses jose-JWT in einem httpOnly-Cookie, das sowohl den Nutzer als auch die aktive Organisation trägt. Kombiniert mit Redis-gestützter Ratenbegrenzung, die graceful degradiert, und HMAC-CSRF-Tokens, die gegen den Request-Origin validiert werden.

Stripe-Abrechnung für kostenpflichtige Berichte

Stripe Checkout plus Webhook-Verarbeitung für einen kostenpflichtigen Compliance-Bericht, wobei der Webhook den rohen Request-Body zur Signaturprüfung liest. Die Verkabelung ist vollständig und im Labor getestet; sie wurde nicht gegen einen echten Kundenstamm betrieben.

Tech-Stack

Next.js 16Prisma 7PostgreSQLStripeCustom JWT

Was zuerst gebrochen ist

▸
Eine generische Assessment-Engine schlägt neun maßgeschneiderte. Jedes Framework — DSGVO, NIS2, AI Act, KRITIS und die übrigen — ist nur ein anderer Satz aus Fragen und Empfehlungen, der gegen dasselbe Datenmodell und Routing aufgelöst wird. Der schwierige Teil ist nicht das Hinzufügen des neunten Frameworks, sondern die Abstraktion so zu entwerfen, dass das neunte fast nichts kostet.
▸
Compliance-Nachweise müssen append-only sein, sonst sind sie wertlos. Ein Einwilligungs- oder Kontrolldatensatz, der sich nachträglich ändern lässt, übersteht kein Audit — deshalb ist das Protokoll bewusst nur einfügbar. Diese Vorgabe hat das Schema weit stärker geprägt als jede UI-Entscheidung.
▸
Mandantentrennung ist ein Problem der Datenschicht, nicht der Oberfläche. Jedes Assessment, jedes Dokument und jeder Bericht wird über eine Organisations-ID im Session-Token isoliert. Diese Trennung einmal richtig zu machen — statt pro Feature — verhindert, dass Mandantendaten zwischen Organisationen durchsickern.

Ergebnis

Ein funktionierendes, selbst gehostetes System, das neun Compliance-Frameworks hinter einer mandantenfähigen Engine bündelt, geteilte Kontrollen über sie hinweg abbildet und Nachweise in einem nur einfügbaren Speicher hält — vollständig in einem lokalen Labor laufend, ohne Cloud-Abhängigkeit. Es ist ein ehrlicher Nachweis der Architektur, kein ausgeliefertes kommerzielles Produkt: Der Abrechnungspfad ist verdrahtet, aber von echten Kunden ungenutzt, und der Wert liegt in strukturierter Nachweissammlung und Bewertung, nicht in rechtlicher Zertifizierung.

Ehrliche Grenzen

Dies ist eine selbst gehostete, mandantenfähige Compliance-App, die ich allein gebaut habe und in einem lokalen Labor betreibe — der alte VPS ist stillgelegt. Die Stripe-Abrechnung ist durchgängig verdrahtet (Checkout plus Webhooks für einen kostenpflichtigen Bericht), aber es steht kein echter Kundenstamm dahinter; betrachten Sie es als funktionierenden Nachweis, nicht als Umsatzquelle. Die Framework-Abdeckung ist ein Workflow zur Nachweissammlung und Bewertung — sie hilft, Kontrollen und Dokumente gegen neun deutsche und internationale Frameworks zu ordnen — keine Rechtsberatung, und sie zertifiziert für sich genommen nichts.