Skip to main content
Home / Portfolio / C3 Compliance
Compliance

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.

C3 Compliance — German compliance — DSGVO, NIS2, AI Act + 6 more

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

Generic assessment engine across nine frameworks
Rather than nine code paths, one engine resolves the questions, recommendations and storage model for whichever framework is requested, routed by a framework slug. Adding or revising a framework is a data change — a new question set and recommendation set — not a new subsystem.
Multi-tenant organisation scoping
An Organization model plus an org-switcher in the UI, with the active organisation id embedded in the session JWT. Assessments, regulatory alerts, documents and reports are all isolated per organisation so one tenant never sees another's data.
Cross-framework control mapping
Because every framework is modelled against the same control vocabulary, a single technical or organisational measure can be shown to satisfy obligations under DSGVO, ISO 27001, NIS2 and others simultaneously — the core reason to unify them rather than run nine separate trackers.
Append-only evidence and consent log
Consent and control records are insert-only so history cannot be rewritten after the fact. This is a deliberate immutability constraint at the data layer, not a feature toggle, and it is what makes the collected evidence defensible in an audit.
Custom JWT auth with per-tenant session context
Stateless jose JWT in an httpOnly cookie, carrying both the user and the active organisation. Paired with Redis-backed rate limiting that degrades gracefully and HMAC CSRF tokens validated against the request origin.
Stripe billing for paid reports
Stripe Checkout plus webhook handling for a paid compliance report, with the webhook reading the raw request body for signature verification. The plumbing is complete and tested in the lab; it has not been run against a real customer base.

Tech stack

Next.js 16Prisma 7PostgreSQLStripeCustom JWT

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.

Related reading

← Back to portfolio