Für Founder, die coden

SOC 2 & ISO 27001 für technische Founder

Du hast das Produkt gebaut. Compliance kannst du auch — wenn das Tool deine Sprache spricht. AuditBadger ersetzt Berater durch Software für jemanden, der Docs liest, statt Meetings zu buchen.

01 / Bist du das

Kommt dir das bekannt vor?

Du bist der technische Co-Founder oder Solo-CTO
Du liest lieber eine Docs-Seite, als in einem Beratungs-Call zu sitzen
Du kannst IAM konfigurieren, Policies-as-Code schreiben und trotzdem shippen
Du willst Compliance-Wissen besitzen, nicht mieten
02 / Warum es anders ist

Warum Compliance dich anders trifft.

01

Berater sind für ihr Modell gebaut, nicht für deins

Ihr Playbook setzt einen Compliance-Manager auf deiner Seite voraus, der Übergaben entgegennimmt. Den hast du nicht. Du bist er — und hättest gern ein Tool, das sich entsprechend verhält.

02

Templates für Firmen, die du nicht bist

100-Seiten-Richtlinienpakete für 500-Personen-Organisationen. Du brauchst Richtlinien, die beschreiben, was ihr wirklich tut — kein Boilerplate, das du keinem Engineer zeigen möchtest.

03

Nachweiserfassung ist ein Zeitfresser

Screenshots, CSV-Exporte, Slack-Threads auf der Jagd nach Zuständigkeiten. Genau die Sorte Fleißarbeit, die ein technischer Founder niemals machen sollte.

03 / Ein durchgerechnetes Beispiel

Wie ein technischer Founder ein Access-Review erledigt, ohne dass es zur Nebenquest wird

Vierteljährliche Access-Reviews gehören zu den häufigsten SOC 2-Findings — nicht weil sie schwer wären, sondern weil sie durchrutschen, wenn niemand sie besitzt. So führt ein technischer Founder eins in unter einer Stunde durch, mit vollständiger Audit-Evidenz, ohne jemandem hinterherzulaufen.

Schritt 01

AuditBadger zieht den aktuellen IAM-Zustand aus AWS, GCP, Azure, DigitalOcean, Scaleway, GitHub und Google Workspace über Read-only-Integrationen. Du exportierst keine CSVs; das System tut es.

Schritt 02

Änderungen seit dem letzten Review werden markiert: neue Nutzer, erhöhte Berechtigungen, inaktive Konten. Du schaust nur auf Deltas, nicht auf die ganze Liste — der einzige Grund, warum das solo machbar ist.

Schritt 03

Für jeden markierten Eintrag genehmigst, entziehst oder stufst du direkt in der Plattform ab. Die Entscheidung wird mit deinem Nutzer, Zeitstempel und Begründung protokolliert. Dieses Protokoll IST der Nachweis.

Schritt 04

Aktionen, die Änderungen im Quellsystem erfordern (z. B. einen GitHub-Admin entfernen), erzeugen einen einzeiligen CLI-Befehl oder einen vorbefüllten PR-Link. Du führst aus; das System bestätigt die Zustandsänderung beim nächsten Sync.

Schritt 05

Quartalsreview abgeschlossen. Das Nachweispaket — Teilnehmerliste, geprüfte Deltas, getroffene Entscheidungen, ausgeführte Aktionen — wird automatisch erzeugt und an die relevanten Controls gehängt (CC6.1, CC6.3 für SOC 2; A.5.18 für ISO 27001).

Fazit

Der Job eines Compliance-Tools für einen technischen Founder ist es, die Zeremonie zu entfernen und nur die echten Entscheidungen übrig zu lassen. Alles, was hier ein Mensch tut, ist eine Entscheidung — keine Aufgabe.

04 / Zwei Frameworks

SOC 2 und ISO 27001, zugeschnitten auf deine Realität.

Eine Plattform, zwei Frameworks. Wähl eins, starte mit beiden oder wechsle später.

SOC 2

Der Bericht, nach dem US-Käufer fragen.

  • Controls und Nachweise als System modelliert, nicht als Checkliste
  • Automatische Kollektoren für AWS, GCP, Azure, DigitalOcean, Scaleway, GitHub, Cloudflare, FleetDM — einmal verbinden
  • Richtlinien aus deinem echten Stack generiert, lesbar wie Source-of-Truth-Docs
  • Direkte Kommunikation mit deinem Auditor, keine Zwischenschicht
SOC 2 entdecken →
ISO 27001

Das Zertifikat, das europäische und Enterprise-Käufer sehen wollen.

  • Ein ISMS, über das du nachdenken kannst — kein 300-Seiten-Ordner
  • SoA und Risikoregister als lebende Dokumente, nicht als Excel-Dateien
  • Zertifizierungsfahrplan mit klaren technischen Deliverables
  • Scope-Entscheidungen, die du dem Auditor technisch begründen kannst
ISO 27001 entdecken →
05 / Die ersten 60 Tage

Wie die ersten 60 Tage wirklich aussehen.

Keine Marketing-Timeline — die echte Abfolge, die wir bei Teams wie deinem sehen.

Woche 1

Das System lesen

Überflieg das Control-Modell der Plattform von vorn bis hinten. Ein Leseabend ersetzt drei Discovery-Calls. Du weißt, worauf das Audit wirklich achtet, bevor du irgendetwas schreibst.

Woche 2

Integrieren und inventarisieren

AWS/GCP/Azure/DigitalOcean/Scaleway/GitHub/Cloudflare verbinden. Die Plattform inventarisiert Assets, Nutzer und Lieferanten automatisch. Verbring deine Zeit mit dem Review des Ergebnisses, nicht mit dessen Erstellung.

Wochen 3–4

Scope und Richtlinien

Definiere den Audit-Scope in der Plattform (was drin ist, was ausgeklammert wird, warum). Generiere und passe Richtlinien für deinen Stack an. Als technischer Founder willst du sie lesen — und sie sind lesbar geschrieben.

Wochen 4–5

Risiken, Controls, Lücken

Führe die Risikobewertung gegen dein Inventar aus. Die Plattform zeigt, welche Controls Lücken haben; du behebst sie als Engineering-Arbeit (was sie auch sind — MFA erzwingen, Backup-Tests, Logging-Abdeckung).

Wochen 5–7

Übergabe ans Audit

Walkthrough mit dem Auditor. Deine System Description liest sich wie gute technische Dokumentation, weil du sie so geschrieben hast. Die Fieldwork-Phase ist ab hier mechanisch.

06 / So funktioniert es

So löst AuditBadger das.

KI-Assistent, der Engineer spricht

Frag in Klartext: 'Reicht GitHub Actions OIDC für die Auditor-Erwartungen an Deployment-Zugriff?' Bekomm eine konkrete Antwort mit Bezug auf dein eigenes Setup. Keine abrechenbare Beraterstunde.

Mehr erfahren →

Read-only-Integrationen, keine Screenshots

Die Plattform liest deinen Cloud- und Source-Control-Zustand direkt. Was nicht automatisierbar ist, wird markiert — du machst nur dort Handarbeit, wo sie wirklich nötig ist.

Mehr erfahren →

Asset-Inventar als Source of Truth

Dein Inventar ist kein vergammelndes Spreadsheet, sondern eine Live-Sicht auf deine Umgebung, aktualisiert aus den Integrationen. Drift fällt sofort auf.

Mehr erfahren →

Risikoregister wie ein Postmortem-Doc

So geschrieben, dass ein Engineer es respektiert — Bedrohung, Wahrscheinlichkeit, Auswirkung, mitigierende Controls, Restrisiko, Verantwortlicher. Ohne Consulting-Füllstoff.

Mehr erfahren →

Richtlinien, lesbar wie Docs

Aus deinem Stack generiert, versioniert, diff-bar. Du kannst dein Team darauf zeigen, statt so zu tun, als wäre ein PDF, das niemand liest, eine echte Richtlinie.

Mehr erfahren →

Lieferantenmanagement ohne Zeremonie

Verfolge Lieferanten, geteilte Daten, Verträge und Review-Rhythmus. Re-Assessments sind Ein-Klick-Updates, keine neuen Fragebögen von null.

Mehr erfahren →
07 / Was Auditoren fragen

Was Auditoren Teams wie deinem wirklich fragen.

Echte Fragen aus SOC 2- und ISO 27001-Audits für deine Kohorte — und wie eine gute Antwort aussieht.

Q

Wer ist der benannte Security- und Compliance-Verantwortliche, und was ist sein technischer Hintergrund?

A

Dich selbst zu benennen (CTO / technischer Co-Founder) ist eine vollständige Antwort. Der Auditor will wissen, dass ein Mensch verantwortlich ist und die Kompetenz hat zu entscheiden. Die Antwort, die er nicht hören will: 'Das gehört allen'.

Q

Führ mich durch eine kürzliche Produktionsänderung.

A

Zeig den ganzen Pfad: Code-Änderung, Review, CI, Deployment, Logging. Der Auditor mappt deinen echten Workflow auf Controls wie CC8.1 (Change Management). Deine GitHub- und CI-Logs sind meist schon der Nachweis; du musst nur wissen, wohin du zeigst.

Q

Wo liegen eure Richtlinien, wer hat sie geschrieben, und wann wurden sie zuletzt geprüft?

A

Der Auditor prüft, dass es keine kopierten Templates ohne Besitzer sind. In AuditBadger verfasste Richtlinien mit deinem Namen und Review-Datum schlagen ein Berater-PDF von vor 18 Monaten.

Q

Zeig mir, wie ihr einen Vorfall erkennt und darauf reagiert.

A

Deck die Erkennungsquelle ab (Alerts, Logs), den Eskalationspfad, das Runbook und das Post-Incident-Review. Der Auditor braucht kein perfektes PagerDuty-Setup — er braucht Belege, dass du das durchdacht hast und ein aktuelles Beispiel zeigen kannst.

08 / FAQ

Fragen, die wir oft hören.

Kann ein technischer Founder SOC 2 wirklich allein stemmen?

Ja. Bei SOC 2 geht es um dokumentierte, konsistente Praxis — nicht um Headcount. Was Solo-Anläufe scheitern lässt, ist schlechtes Tooling, das Founder in manuelle Nachweiserfassung zwingt. Mit automatischen Kollektoren und Klartext-Control-Mapping kann ein technischer Founder es End-to-End besitzen.

Was unterscheidet das vom Berater-Engagement?

Ein Berater übergibt dir einen Prozess, der von ihm abhängt. AuditBadger gibt dir den Prozess plus die Tools, ihn zu betreiben. Das Wissen gehört dir und verzinst sich — und einen Auditor kannst du trotzdem direkt dazuholen, wenn es so weit ist.

Muss ich Compliance-Experte werden?

Nein. Du musst Entscheidungen über deine eigene Firma treffen. AuditBadger übersetzt Compliance-Sprache in Engineering-Sprache und zurück, damit du nie raten musst, was ein Auditor will.

Und die Dinge, die wirklich einen Menschen brauchen?

Das Audit selbst erfordert einen lizenzierten Auditor (für SOC 2) oder eine Zertifizierungsstelle (für ISO 27001). Wir verbinden dich mit unseren. Alles andere — Vorbereitung, Nachweise, Richtlinien, Risiken — schaffst du mit der Plattform.

Ich habe schon einige Richtlinien geschrieben. Kann ich sie importieren?

Ja. AuditBadger lässt dich eigene Richtlinien mitbringen und mappt sie gegen die Control-Frameworks, damit du Lücken siehst. Du startest nicht bei null.

Was passiert, wenn ich später jemanden dafür einstelle?

Die Person erbt ein funktionierendes System mit vollständigem Audit-Trail und lebenden Nachweisen — keinen Ordner zum Reverse-Engineeren. Das macht die Übergabe zu Stunden statt Monaten.

Bereit, das nicht länger aufzuschieben?

Hol dir SOC 2 oder ISO 27001 zu deinen Bedingungen — ohne Berater, ohne Vollzeit-Compliance-Hire, ohne das Grauen.