C3 Compliance
German compliance — DSGVO, NIS2, AI Act + 6 more
Built by Rogue AI · Self-hosted multi-tenant compliance app · Self-hosted · Local lab
Built solo over a series of focused build sprints in the lab.
The problem
German SMEs face a stack of overlapping compliance regimes — DSGVO, NIS2, the AI Act, KRITIS, ISO 27001, SOC 2, TISAX, BAIT, VAIT — and each is usually handled as its own spreadsheet, its own consultant and its own pile of evidence. The overlap is enormous: a single technical control often satisfies obligations under several frameworks at once, but nothing connects them, so the same evidence gets re-gathered again and again. C3 exists to model all nine in one place, map shared controls across them, and keep the evidence in one auditable system instead of nine disconnected ones.
What I built
A multi-tenant Next.js 16 application where an organisation can run assessments against any of the nine frameworks through a single generic engine, attach evidence and documents per framework, and see where one control answers obligations in several regimes at once. Authentication is a custom jose JWT in an httpOnly cookie that also carries the active organisation, so every query is tenant-scoped. Records that need to be audit-safe — consent and control logs — are insert-only. Stripe is wired for a paid compliance report. It runs as three hardened Docker containers (app, PostgreSQL, Redis) in a local lab; there is no managed cloud behind it.
Architecture
Tech stack
What broke first
- ▸
One generic assessment engine beats nine bespoke ones. Each framework — DSGVO, NIS2, AI Act, KRITIS and the rest — is just a different set of questions and recommendations resolved against the same data model and routing. The hard part is not adding the ninth framework; it is designing the abstraction so the ninth costs almost nothing.
- ▸
Compliance evidence has to be append-only or it is worthless. A consent or control record that can be edited after the fact cannot survive an audit, so the log is insert-only by design. That constraint shaped the schema far more than any UI decision.
- ▸
Multi-tenant isolation is a data-layer problem, not a UI one. Every assessment, document and report is scoped to an organisation id carried in the session token. Getting that scoping right once — rather than per-feature — is what keeps tenant data from leaking across orgs.
Outcome
A working, self-hosted system that consolidates nine compliance frameworks behind one multi-tenant engine, maps shared controls across them, and keeps evidence in an append-only store — running entirely in a local lab with no cloud dependency. It is an honest proof of the architecture rather than a deployed commercial product: the billing path is wired but unexercised by real customers, and the value it delivers is structured evidence collection and assessment, not legal certification.
Honest limits
This is a self-hosted, multi-tenant compliance app I built solo and run in a local lab — the old VPS is retired. Stripe billing is wired end to end (checkout plus webhooks for a paid report), but there is no real customer base behind it; treat it as a working proof, not a revenue line. The framework coverage is an evidence-collection and assessment workflow — it helps you organise controls and documents against nine German and international frameworks — not legal advice, and it does not certify anything on its own.
