📊 Audit Übersicht
Status: Dokumentation validiert gegen Code ✅
Letzte Validierung: 11.01.2026 | Nächste Überprüfung: März 2026
Zielgruppe: IT-Leitung, Entwicklungsteam, Security/Compliance
Coverage: 0.32% (Baseline) → Roadmap: 30% (3M) → 50% (6M) → 80% (12M)
Letzte Validierung: 11.01.2026 | Nächste Überprüfung: März 2026
Zielgruppe: IT-Leitung, Entwicklungsteam, Security/Compliance
Coverage: 0.32% (Baseline) → Roadmap: 30% (3M) → 50% (6M) → 80% (12M)
Executive Summary
Dieses Audit dient als rotes Faden-Prüfmodell für die schrittweise Evaluierung und Verbesserung eurer SaaS-Struktur. Es basiert auf bewährten Praktiken in 8 Kernbereichen mit jeweils Reifegradscore (0–5), Checklisten und Handlungsplan.
Bewertungsmethodik
Reifegradskala 0–5:
0 = Nicht vorhanden | 1 = Ad-hoc | 2 = Definiert | 3 = Etabliert | 4 = Gemessen | 5 = Optimierend
0 = Nicht vorhanden | 1 = Ad-hoc | 2 = Definiert | 3 = Etabliert | 4 = Gemessen | 5 = Optimierend
Aktuelle Scores
🔧 Engineering Excellence
/ 5
🏗️ Software-Architektur
/ 5
🔐 Identity & Security
/ 5
⚙️ DevOps & Monitoring
/ 5
📚 Dokumentation
/ 5
🤖 Claude Code Integration
/ 5
⚠️ Risk & Supply Chain
/ 5
📊 GESAMT-DURCHSCHNITT
2.5 / 5
Fortschritt zu den Zielen
6-Monatsziel: Durchschnitt 3.0 / 5
1-Jahrziel: Durchschnitt 4.5 / 5 (Exzellenz)
💻 Engineering Excellence
1.1 Allgemeine Entwicklungspraktiken
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Coding Standards dokumentiert | ✅ CLAUDE.md mit Coding Standards, Naming Conventions | |
| Code Reviews verpflichtend | ✅ Branch Protection + PR Template aktiv | |
| Branch Protection auf main | ✅ develop → main Workflow, PRs erforderlich | |
| Automatisiertes Linting/Formatting | ✅ GitHub Actions: npm run lint bei jedem Push/PR | |
| SOLID-Prinzipien werden gelebt | SRP, OCP, LSP, ISP, DIP erkennbar? | |
| Keine Copy-Paste-Logik | Logik ist ausgelagert in Services/Utils? | |
| Aussagekräftige Variablennamen | ✅ camelCase, PascalCase, Naming Conventions in CLAUDE.md | |
| Kurze, fokussierte Funktionen | Max. 20–30 Zeilen? |
Score 1.1 (Entwicklungspraktiken): / 5
1.2 Testing & Qualitätssicherung
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Unit Tests geschrieben | ✅ 92 Unit + 53 Integration + 19 Rate-Limit Tests | Coverage: 0.32% | Roadmap: 30%→50%→80% | |
| Integration Tests für kritische Flows | ✅ 53 Integration Tests (Feed, Auth, Gamification) | Commit: e692914 | |
| End-to-End Tests für Hauptfunktionen | ✅ Playwright E2E Setup (Feed, Gamification) | Commit: 27bbc9c | |
| Test-Ergebnisse in CI/CD sichtbar | ✅ GitHub Actions zeigt Test-Ergebnisse in PR | |
| Manuelles Testing systematisch dokumentiert | ✅ docs/TEST_STRATEGIE.md - Aktueller Stand + Roadmap (validiert 11.01.2026) | |
| Performance-Tests durchgeführt | Last-Tests, Response-Time-Benchmarks? | |
| Security-spezifische Tests | OWASP Top-10, Auth, Input Validation? |
Score 1.2 (Testing): / 5
1.3 Refactoring & Technische Schuld
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Regelmäßige Code-Reviews auf Schuld | ✅ Duplizierte Auth-Logik in Middleware extrahiert (13% weniger Code) | |
| Abhängigkeiten regelmäßig aktualisiert | ✅ Dependabot aktiviert - automatische PRs | |
| Veraltete Libraries identifiziert | ✅ Dependabot Security Alerts aktiviert | |
| Refactoring-Zeit budgetiert | 20% der Sprintkapa für Schuld-Abbau? | |
| Module/Services klar abgegrenzt | ✅ Auth-Middleware extrahiert (src/lib/api/) | Commit: 09cb435 | |
| Dokumentation wird mit Code aktualisiert | ✅ CLAUDE.md wird bei jeder Session gepflegt |
Score 1.3 (Technische Schuld): / 5
1.4 Branching-Strategie & Review-Prozess
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Branching-Strategie definiert | ✅ develop → main Workflow in CLAUDE.md dokumentiert | |
| Feature Branches pro Änderung | ✅ Branch Protection verhindert direkte Commits | |
| Verpflichtende Pull Requests | ✅ Branch Protection auf main + develop aktiv | |
| Review-Checkliste definiert | ✅ .github/PULL_REQUEST_TEMPLATE.md + docs/PR_REVIEW_CHECKLISTE.md (11.01.2026) | |
| Mind. 2 Reviewer bei kritischem Code | Für Auth, Payment, Security? | |
| Pair/Mob Programming etabliert | Für komplexe Features? | |
| Automatisierte Checks als PR-Gate | ✅ GitHub Actions: Lint + Test + Build müssen grün sein |
Score 1.4 (Branching & Review): / 5
1.5 Teststrategie & Abdeckung
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Testpyramide definiert | ✅ docs/TEST_STRATEGIE.md (Unit→Integration→E2E Pyramide) | |
| Coverage-Ziele je Layer | ✅ Roadmap: 0%→30% (3M)→50% (6M)→80% (12M) | jest.config.js konfiguriert | |
| Regressionstests automatisiert | Kritische Bugs kommen nicht wieder? | |
| Negative & Edge-Case Tests | Fehlerpfade explizit getestet? | |
| Contract-Tests für Services/APIs | Zwischen Microservices? | |
| Performance-/Load-Tests in CI optional | Für kritische Endpunkte? |
Score 1.5 (Teststrategie): / 5
🏗️ Software-Architektur & Cloud-Native Design
2.1 Architektur-Übersicht
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| C4-Diagramm existiert | ✅ docs/ARCHITEKTUR_C4.md - 35+ Routes, 24 lib-Module (validiert 11.01.2026) | |
| Cloud Provider gewählt & begründet | ✅ Hetzner Deutschland - DSGVO-konform, kein CLOUD Act | |
| Managed Services genutzt | ✅ Supabase (Auth, PostgreSQL, Storage, Realtime) | |
| Stateless API / Service Design | ✅ Next.js API Routes - kein Server-State | |
| Horizontale Skalierung möglich | ✅ Coolify kann mehrere Instanzen deployen | |
| Load Balancing konfiguriert | ✅ Traefik Reverse Proxy mit Auto-Discovery | |
| Database Sharding geplant | Strategie für Wachstum definiert? | |
| Caching-Strategie existiert | ✅ docs/CACHING_STRATEGIE.md - React Query gcTime=10min, retry=1 (validiert) |
Score 2.1 (Architektur): / 5
2.2 Multi-Tenancy
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Multi-Tenancy-Modell definiert | ✅ Single-Tenant: Separate DB pro Club (höchste Isolation) | |
| Tenant-ID in allen Queries | ✅ RLS mit auth.uid() - automatisch gefiltert | |
| Kreuzmanndanten-Zugriff unmöglich | ✅ Physisch getrennte Datenbanken pro Club | |
| Tenant-Metadaten sauber getrennt | ✅ club_settings Tabelle pro Datenbank | |
| Data Isolation Tests | Eindeutige Test Cases für Isolation? | |
| Tenant-spezifische Quotas/Rate Limits | ✅ Rate Limiting implementiert (Posts:10/h, AI:20/h) | Commit: b4a57c1 |
Score 2.2 (Multi-Tenancy): / 5
2.3 Datenmodell & Persistenz
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Datenbankschema dokumentiert | ✅ docs/DATENBANK_ERD.md - 125 Tabellen (validiert 11.01.2026) | |
| Backups automatisiert & getestet | ✅ backup-postgres.sh täglich 03:00 + Offsite Storage Box | |
| Migrations-Strategie definiert | ✅ app_migrations Tabelle mit Versionierung YYYY.MM.DD.NN | |
| Datenverschlüsselung at rest | DB-Verschlüsselung, Secrets Manager? | |
| Monitoring der DB-Performance | ✅ db-health.sh + Index-Analyse durchgeführt | |
| Datenretention-Policies definiert | ✅ docs/DATENRETENTION_POLICY.md - DSGVO Art.17 konform (11.01.2026) | |
| Indexierung optimiert | ✅ 148 neue Indizes erstellt | docs/INDEX_OPTIMIERUNG.md | Commit: 8184fa0 | |
| Read Replicas für Reporting | Analytische Queries belasten nicht Prod? |
Score 2.3 (Datenmodell): / 5
2.4 Microservices, Kubernetes & IaC
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Service-Schnittstellen klar definiert | ✅ 35+ API Routes in CLAUDE.md dokumentiert | |
| Kubernetes/Orchestrierung dokumentiert | ✅ Docker + Coolify - Container-Übersicht in CLAUDE.md | |
| Infrastructure-as-Code genutzt | Terraform, Pulumi, CloudFormation? | |
| IaC-Versionierung & Code-Review | Infra-Änderungen über PR + Review? | |
| IaC-Security-Scans aktiv | Misconfig-Checks vorhanden? | |
| Ressourcen-Quotas & Limits gesetzt | CPU/Memory-Limits, PodDisruptionBudgets? | |
| Service Mesh/Zero-Trust intern | mTLS zwischen Services? |
Score 2.4 (Microservices & IaC): / 5
🔐 Sicherheit & Access Control
3.1 Identität & Authentifizierung
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| SSO implementiert | SAML, OIDC für interne Nutzer? | |
| MFA verpflichtend (Admin) | TOTP / Yubikey für sensible Rollen? | |
| MFA für Kunden | Angeboten? Für kritische Funktionen erzwungen? | |
| Passwort-Policy durchgesetzt | Länge, Komplexität, Ablauf? | |
| Session-Timeouts konfiguriert | Inaktivität / kritische Aktionen? | |
| Brute-Force-Schutz aktiv | Rate Limiting, Account Lockout? | |
| JWT/Token-basierte Auth | Nicht session-basiert? Token Expiry? | |
| Sichere Cookie-Einstellungen | HttpOnly, Secure, SameSite? |
Score 3.1 (AuthN/AuthZ): / 5
3.2 Rollen & Zugriffskontrolle (RBAC)
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Standardrollen definiert | Owner, Admin, Editor, Viewer? | |
| Berechtigungen zu Rollen gemappt | Action × Resource Matrix? | |
| Least Privilege angewandt | Minimal notwendige Rechte? | |
| Segregation of Duties | Kritische Aktionen auf mehrere Rollen? | |
| Role-Hierarchie klar | Vererbungslogik dokumentiert? | |
| Tenant-bewusstes RBAC | Admin in A, Viewer in B? | |
| Keine Global Superadmins | Admins für spezifische Tenant? | |
| Custom Roles möglich | Kunden können eigene Rollen definieren? | |
| Access Review Prozess existiert | Quartalsweise Überprüfung? |
Score 3.2 (RBAC): / 5
3.3 Identitäts-Governance
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Joiner-Mover-Leaver Prozess | Automatisiertes Onboarding & Offboarding? | |
| Service Accounts inventarisiert | Alle API-Keys, Secrets dokumentiert? | |
| API-Keys rotiert regelmäßig | Max. 90 Tage Gültigkeitsdauer? | |
| Secrets Manager zentral | Vault, AWS Secrets Manager? | |
| Keine hardcoded Credentials | Code/Konfiguration frei von Secrets? | |
| Service Accounts haben Least Privilege | Jeder Bot nur minimal nötige Rechte? | |
| Maschinelle Identitäten monitored | Verdächtige Service-Account-Aktivitäten erkannt? | |
| Inaktive Accounts deprovisioned | Alte Nutzer/Accounts abgebaut? |
Score 3.3 (Identity Governance): / 5
3.4 Daten & Integrationssicherheit
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| TLS 1.3+ überall | Alle Verbindungen verschlüsselt? | |
| Secrets Management | Nicht hardcoded? | |
| API-Keys rotiert | Keine statischen Secrets? | |
| OAuth/SCIM für Integrationen | Nicht statische API-Keys? | |
| Datenexport limitiert | Nur berechtigte Rollen? | |
| Webhooks authenticated | Signature Verification? | |
| PII/Sensible Daten maskiert | In Logs, Support-Zugriff? | |
| Datenschutz-Richtlinien dokumentiert | GDPR, DSGVO, Retention? |
Score 3.4 (Data Protection): / 5
3.5 Netzwerk & Zero Trust
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Admin-Zugriffe nur über VPN/ZTNA | Nicht direkt aus Internet? | |
| Netzwerk-Segmentierung | Frontend, API, DB in getrennten Subnetzen? | |
| WAF (Web Application Firewall) | Vor Frontend/API? | |
| DDoS-Schutz | Cloud-Provider oder externe Lösung? | |
| SSH-Schlüssel & Bastion-Host | Nicht direkte SSH zu Prod? | |
| Security Groups / Firewall Rules | Least Privilege? | |
| Monitoring ungewöhnlicher Zugriffe | Logs analysiert? Anomalie-Erkennung? |
Score 3.5 (Netzwerksicherheit): / 5
3.6 Compliance & Audit
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Audit Logs für kritische Aktionen | Logins, Admin-Änderungen, Datenexporte? | |
| Log-Retention entsprechend Policy | Wie lange? Unveränderbar? | |
| Sicherheits-Incident Prozess | Wer meldet? Eskalation? Dokumentation? | |
| Penetrationstests durchgeführt | Jährlich? Ergebnisse adressiert? | |
| Vulnerability Scanning | Automatisiert in CI/CD? Regelmäßig? | |
| Data Protection Impact Assessment | DPIA durchgeführt? Dokumentiert? | |
| Datenschutz-Beauftragter benannt | Falls DSGVO-relevant? | |
| AI Act Compliance (Claude Code) | Falls KI-Nutzung reguliert? |
Score 3.6 (Compliance & Audit): / 5
⚙️ DevOps & Deployment
4.1 CI/CD Pipeline
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Automatisierter Build | ✅ Coolify Webhooks: develop → test, main → demo | |
| Automatisierte Tests in Pipeline | ✅ GitHub Actions bei Push/PR | |
| Code Quality Checks | ✅ npm run lint in Pipeline | |
| SAST (Security Analysis) | Automatisiert Sicherheits-Schwachstellen gefunden? | |
| SCA (Dependency Scanning) | ✅ GitHub Dependabot aktiviert | |
| Secret Scanning | ✅ GitHub Secret Scanning aktiviert | |
| Container Scanning | Docker Images auf Vulnerabilities? | |
| Automatisiertes Deployment zu Staging | Nach erfolgreicher Pipeline? | |
| Manual Approval vor Prod | Gated Release? Dokumentation? | |
| Blue/Green oder Canary Deployment | Risikoreduziertes Rollout? | |
| Automatisierter Rollback | Fehler in Prod → schnell zurückfahren? | |
| Deployment-Fenster dokumentiert | Wann sind Deployments erlaubt? |
Score 4.1 (CI/CD): / 5
4.2 Überwachung & Observability
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Zentrales Logging | ELK, Splunk, DataDog, etc.? | |
| Metriken gesammelt | CPU, Memory, Response Times, Error Rates? | |
| Distributed Tracing | Request-Flows über Services? | |
| Alerting konfiguriert | On-Call wird alarmiert? | |
| Runbooks dokumentiert | Wie behebt man häufige Incidents? | |
| Status Page öffentlich | Kunden sehen Systemstatus? | |
| Incident Post-Mortems | Nach größeren Ausfällen? Lessons Learned? | |
| SLA/SLO definiert | Uptime, Response Time Ziele? | |
| Backup Monitoring | Backups regelmäßig getestet? | |
| Security-Event Monitoring | Verdächtige Logins, Massendaten-Exporte? |
Score 4.2 (Monitoring): / 5
4.3 Change Management & Release Governance
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Change-Policy dokumentiert | Standard vs Major vs Hotfix definiert? | |
| Change Approval Prozess | Wer genehmigt was? Risiko-basiert? | |
| Release-Kalender gepflegt | Sichtbar für IT/Business? Freeze-Perioden? | |
| Rollback-Playbooks pro Service | Vor jedem Release vorhanden & getestet? | |
| Post-Deployment Smoke Tests | Automatisiert nach jedem Rollout? | |
| Change-Logs für Kunden & intern | Release Notes, Breaking Changes? |
Score 4.3 (Change Management): / 5
4.4 Incident Response & Disaster Recovery
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Incident Response Policy | Definition, Rollen, Kommunikation? | |
| Incident Runbooks/Playbooks | Für typische Szenarien (DDoS, DB-Ausfall)? | |
| MTTD/MTTR gemessen | KPIs für Erkennung & Behebung? | |
| Regelmäßige Incident-Übungen | Tabletop-Exercises / Game Days? | |
| DR-Plan dokumentiert | RTO/RPO je System definiert? | |
| Failover-Strategien getestet | Region/Zone-Failover realistisch geprobt? | |
| Kalt-/Warm-/Hot-Standby definiert | Pro System entschieden? | |
| Kommunikationsplan bei Major Outage | Interne/Externe Kommunikation? |
Score 4.4 (Incident & DR): / 5
📚 Dokumentation & Knowledge Management
5.1 Dokumentationsstandards
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| README in jedem Repository | ✅ README.md + CLAUDE.md + ENTWICKLERHANDBUCH.md | |
| Architecture Decision Records (ADRs) | Wichtige Entscheidungen mit Kontext? | |
| API-Dokumentation | Swagger/OpenAPI? Automatisch generiert? | |
| Deployment & Ops-Doku | Wie deployt man? Skalierung? | |
| Runbooks für häufige Aufgaben | Troubleshooting, Backups, Failover? | |
| Doku im Repo versioniert | ✅ 6 IT-Audit Docs in docs/ + CLAUDE.md (validiert 11.01.2026) | |
| Doku-Builds in CI/CD | Fehlerhafte Links blockieren Merge? | |
| Regelmäßige Doku-Reviews | Monatlich? Veraltete Inhalte aktualisiert? | |
| Ownership pro Doku-Bereich | Wer ist verantwortlich für Aktualität? |
Score 5.1 (Dokumentationsstandards): / 5
5.2 Code-Kommentierung & Selbstdokumentation
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| JSDoc / Docstring auf Public APIs | Parameter, Return, Exceptions? | |
| Komplexe Logik erklärt | "Why", nicht "What"? | |
| Keine offensichtlichen Kommentare | Selbsterklärender Code? | |
| Sprechende Variablennamen | userCount statt uc? | |
| CLAUDE.md mit Coding Standards | ✅ CLAUDE.md (~2000 Zeilen) + Coding Standards + DB-Schema + Deployment |
Score 5.2 (Code-Dokumentation): / 5
5.3 Knowledge Sharing & Training
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Regelmäßige Tech-Talks/Brownbags | Wissensteilung zu Architektur, Security? | |
| Onboarding-Guides für Rollen | Dev, DevOps, Security, Product? | |
| Training zu Secure Coding | Mind. jährlich? Pflicht? | |
| Lessons Learned Repository | Aus Incidents, Post-Mortems? | |
| AI/Claude Schulungen | Sichere Nutzung, Policy? |
Score 5.3 (Knowledge Sharing): / 5
🤖 Claude Code Integration & AI-Sicherheit
6.1 Claude Code Deployment & Policies
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Enterprise/Team Plan aktiviert | Mit SSO / Admin Controls? | |
| Zentrale Policy dokumentiert | Claude Code Usage Guideline existiert? | |
| Benutzergruppen & Rollen definiert | Wer darf Claude Code nutzen? | |
| MCP-Server konfiguriert | Nur approved MCPs? Nicht beliebig? | |
| Tool-Permissions restriktiv | Shell, HTTP, File-System mit Limits? | |
| Managed Policies aktiviert | Enterprise Admin Controls genutzt? | |
| Workspace-Scoping | Claude Code nur auf Dev-Repos? | |
| Claude Code Logging | Repos, Nutzer, Tools getracked? | |
| AI Governance Framework etabliert | Policy, Freigabeprozesse, Incident Handling? | |
| Audit Trail für AI-Aktivitäten | Wer hat Claude Code wann genutzt? |
Score 6.1 (Claude Deployment): / 5
6.2 Prompt Injection & Data Protection
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Keine Prod-DB-Zugri via Claude | Nur Test/Staging mit Maskierung? | |
| Keine Secrets in Prompts | Team weiß: was darf man Claude geben? | |
| Claude hat keinen DB-Direktzugriff | Keine MCP zu Production-Datenbanken? | |
| Prompt Injection Risiken kommuniziert | Team kennt Risiken? | |
| Review-Pflicht für AI-Code | PR-Checkliste mit "AI-Code?" Check? | |
| SAST/SCA für Claude-Code | Aggressive Security Scanning? | |
| Sandbox für Claude Suggestions | Skripte erst isoliert testen? | |
| Vertrauliche Daten maskiert | Staging-Daten ohne Kundendaten? | |
| Prompt Injection Detection | Tools/Prozess zur Erkennung? |
Score 6.2 (Claude Security): / 5
6.3 Claude Code im Dokumentationsprozess
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| CLAUDE.md im Projekt existiert | Standards, Stil, Do's & Don'ts? | |
| Claude schreibt Doku-Entwürfe | README, ADR, How-to aus Code? | |
| Human Review für Doku verpflichtend | Nicht automatisch committet? | |
| Stil-Konsistenz durchgesetzt | CLAUDE.md Richtlinien befolgt? | |
| Doku im PR-Process enthalten | Checklist: "Docs updated?" | |
| Regelmäßige Doku-Prüfung mit Claude | Monthly: veraltete Stellen? |
Score 6.3 (Claude & Dokumentation): / 5
6.4 AI Governance & Business Alignment
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| AI Use Cases klar definiert | Welche Business-Probleme löst Claude? | |
| AI Risk Assessment durchgeführt | Bias, Datenschutz, AI Act? | |
| AI-Model/Tool Ownership | Wer verantwortet Qualität & Security? | |
| Metriken für AI-Nutzen | Zeitersparnis, Qualität, Business Value? | |
| Business Roadmap integriert IT/AI | Initiativen mit Zielen verknüpft? |
Score 6.4 (AI Governance): / 5
⚠️ Risk Management & Software Supply Chain
7.1 Formales Risk Management
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Risiko-Register existiert | Assets, Bedrohungen dokumentiert? | |
| Risk Assessment durchgeführt | Impact × Likelihood-Matrix? | |
| Akzeptiertes Restrisiko definiert | Was ist tolerable? Wer genehmigt? | |
| Risikobehandlung geplant | Mitigations-Strategien? | |
| Risikobehandlung monitored | Sind Mitigationen wirksam? | |
| SaaS-spezifische Risiken bewertet | Fehlkonfigurationen, unsichere APIs? | |
| Regelm. Risiko-Reviews | Quartalsweise Neubewerung? |
Score 7.1 (Risk Management): / 5
7.2 Software Supply Chain & Abhängigkeiten
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| SBOM für alle Komponenten | Dependencies, Libraries dokumentiert? | |
| Dependency Scanning automatisiert | CVE-Datenbanken abgefragt? | |
| Known Vulnerabilities getracked | Patches geplant & eingespielt? | |
| Code Signing & Integrity Checks | Artifact Signing? Verification? | |
| Vendor-Assessment durchgeführt | Kritische Dritt-SaaS bewertet? | |
| Vendor-Sicherheit monitored | Security Updates von Vendors? | |
| License Compliance prüfen | Open-Source Lizenzen kompatibel? | |
| Kritische Dependencies identifiziert | Welche sind Business-kritisch? |
Score 7.2 (Supply Chain): / 5
7.3 SaaS Integration & Shadow IT
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Angebundene Fremd-SaaS dokumentiert | CRM, Payment, Analytics? | |
| Datenfluss zu SaaS-Anbietern geklärt | Was wird wohin übertragen? Kontrahiert? | |
| Shadow SaaS Monitoring aktiv | Tool zur Erkennung unkontrollierter SaaS? | |
| Shadow AI Nutzung adressiert | Private ChatGPT/Claude-Nutzung? | |
| Berechtigungen in Fremd-SaaS minimal | Nur notwendige Scopes? | |
| Überprivilegierte Integrationen | Regelmäßige Audit? | |
| Dritt-SaaS-Sicherheit bewertet | ISO27001, SOC2, Datenschutz? | |
| Dritt-SaaS-Verbindungen kündbar | Data Retrieval Plan existiert? |
Score 7.3 (SaaS Integration): / 5
7.4 Kontinuierliche Verbesserung & Kultur
| Kriterium | Status | Evidenz / Notiz |
|---|---|---|
| Security Awareness Training | Jährlich? Phishing-Sims? | |
| Schulung: Prompt Injection & AI-Risiken | Entwickler verstehen Risiken? | |
| Schulung: Datenhandling & GDPR | Team weiß: umgang mit PII? | |
| Incident Drills regelmäßig | Scenario-basiertes Trainieren? | |
| Post-Mortem Prozess etabliert | Nach Incidents: Analyse & Lessons? | |
| Metriken zu Security gesammelt | #Incidents, MTTR, Findings? | |
| Security Champion pro Team | Ansprechperson für Security? | |
| Security-Kultur sichtbar gelebt | Security ist Wert, nicht nur Pflicht? |
Score 7.4 (Security Culture): / 5
🗺️ Handlungsplan & Roadmap
Sofortmaßnahmen (Nächstes Wochenende/Woche)
🔴 Phase 1: Sicherheit & Risiken (1–2 Wochen)
- Risiko-Register anlegen (1–2 Std)
- Shadow-SaaS Audit durchführen (2 Std)
- Claude Code Security Policy schreiben (30 min)
- Prod-DB-Zugriff via Claude sichern (1–2 Std)
- Secret Scanning aktivieren (Git-Guardian, Truffles Hog)
- CLAUDE.md Template erstellen (1–2 Std)
Kurzfristig (Nächste 2–3 Wochen)
🟠 Phase 2: Grundlagen (2–3 Wochen)
- SBOM & Dependency Scanning einführen (2–3 Tage)
- Unified Identity Management prüfen (1 Tag)
- RBAC Model dokumentieren (2 Tage)
- Audit Logs aktivieren (1 Tag)
- CI/CD Pipeline erweitern (3–5 Tage) – SAST, SCA, Secret Scanning
- Access Review durchführen (1 Tag)
- Developer-Schulung: Claude Code Best Practices (1 h)
Mittelfristig (Nächster Monat)
🔵 Phase 3: Struktur & Prozesse (4 Wochen)
- Risk Management Prozess implementieren (2–3 Tage)
- Vendor-Management etablieren (2 Tage)
- Dokumentations-Audit durchführen (2–3 Tage)
- Architecture Decision Records (ADRs) erstellen (3–5 Tage)
- Datenbank-Backup Test durchführen (1 Tag)
- Observability ausbauen (3–5 Tage) – Logging, Metriken, Alerts
- Multi-Tenant-Isolation Test durchführen (2–3 Tage)
Längerfristig (Q1–Q2 2026)
🟢 Phase 4: Exzellenz & Zertifizierung (3–6 Monate)
- Penetrationtest durchführen (extern) – OWASP Top 10, AI-Sicherheit
- Cloud-native Architektur weiterentwickeln – Microservices, Kubernetes
- Compliance-Zertifizierungen – ISO 27001, SOC 2, GDPR Audit
- CI/CD Reife steigern – Canary/Blue-Green, automatisierter Rollback
- Doku als Code vollständig etabliert – ADRs, API-Doku, Doku-Bugs
- AI Governance vollständig operationalisiert – Audits, Incident Response
Tracking & KPIs
Monatliche Überprüfung:
✅ Abgeschlossene Aufgaben
⏳ In Bearbeitung (Progress %)
⚠️ Blockers & Herausforderungen
📊 Score-Updates pro Bereich
🎯 Nächste 4 Wochen Planung
✅ Abgeschlossene Aufgaben
⏳ In Bearbeitung (Progress %)
⚠️ Blockers & Herausforderungen
📊 Score-Updates pro Bereich
🎯 Nächste 4 Wochen Planung