leocrm/ENTERPRISE_READINESS_PLAN.md

# LeoCRM — Enterprise-Readiness Plan

**Ziel:** KI und Business-Plattform für kleine bis mittlere Firmen (max. 500 Mitarbeiter)
**Erstellt:** 2026-08-20

---

## 1. RLS (Row Level Security)

### 20 Tabellen ohne RLS in Produktion — Klassifizierung

**Absichtlich kein RLS (10 Tabellen — Auth/System-Tabellen):**
Diese Tabellen brauchen kein RLS weil sie vor der Tenant-Auflösung gebraucht werden oder global sind:
| Tabelle | Grund |
|---------|-------|
| `alembic_version` | Migration-Tracking, global |
| `notification_types` | Globale Type-Definitionen |
| `password_reset_tokens` | Auth vor Tenant-Context |
| `plugin_allowlist` | Globale Plugin-Konfiguration |
| `plugin_migrations` | Globale Plugin-Migration-Tracking |
| `plugins` | Globale Plugin-Registry |
| `sessions` | Auth vor Tenant-Context |
| `tenants` | Die Tenant-Tabelle selbst |
| `user_tenants` | Mapping Users ↔ Tenants |
| `users` | Auth vor Tenant-Context |

**Brauchen RLS (10 Tabellen):**
| Tabelle | Warum RLS nötig | Migration |
|---------|-----------------|----------|
| `ai_decision_records` | Tenant-spezifische AI-Entscheidungen | 0129 |
| `approval_requests` | Tenant-spezifische Approvals | 0129 |
| `automation_agent_run_steps` | Tenant-spezifische Agent-Run-Steps | 0129 |
| `outbox_deliveries` | Tenant-spezifische Event-Zustellungen | 0129 |
| `roles` | Tenant-spezifische Rollen | 0129 |
| `sequences` | Tenant-spezifische Sequenzen | 0129 |
| `wiki_articles` | Tenant-spezifische Wiki-Artikel | 0129 |
| `wiki_article_versions` | Tenant-spezifische Wiki-Versionen | 0129 |
| `wiki_categories` | Tenant-spezifische Wiki-Kategorien | 0129 |
| `marketplace_listings` | Prüfen: Global oder per-Tenant? | 0129 |

### Ablaufplan RLS:
1. Migration 0129 erstellen: `ALTER TABLE ... ENABLE ROW LEVEL SECURITY` + `CREATE POLICY tenant_isolation ON ...`
2. In Test-DB ausführen und verifizieren
3. In Produktion deployen
4. RLS-Tests schreiben: Cross-Tenant-Zugriff muss blockiert werden
5. Verifizieren: `SELECT count(*) FILTER (WHERE rowsecurity=true) FROM pg_tables WHERE schemaname='public'` → muss 123 sein (133 - 10 system)

---

## 2. Security Audit & Penetration Test

### Security Audit (Code-Level)
1. **SQL Injection** — Alle Routes auf Raw-SQL prüfen (`grep -rn 'text(\|execute(\|raw' app/routes/`)
2. **XSS** — Frontend auf `dangerouslySetInnerHTML` prüfen
3. **CSRF** — CSRF Middleware prüfen (vorhanden in `app/core/middleware.py`)
4. **Auth Bypass** — Routes ohne `require_permission` oder `get_current_user` identifizieren
5. **Secret Exposure** — `.env`, API-Keys, Tokens im Code prüfen
6. **Dependency Audit** — `pip-audit` (Python) + `npm audit` (Frontend)
7. **Rate Limiting** — Prüfen ob Rate-Limiting auf kritischen Routes aktiv ist

### Penetration Test (Extern)
1. **OWASP Top 10** Checkliste abarbeiten
2. **Burp Suite / OWASP ZAP** Scan gegen https://crm.media-on.de
3. **Auth Tests** — Session-Hijacking, Cookie-Flags, Login-Brute-Force
4. **API Tests** — Unautorisierte Zugriffe, IDOR (Insecure Direct Object Reference)
5. **Multi-Tenant Tests** — Cross-Tenant Datenzugriff versuchen

### Ablaufplan Security:
1. Code-Level Security Audit (automatisiert, 1 Tag)
2. Dependency Audit (pip-audit + npm audit, 0.5 Tage)
3. Externer Pen-Test (manuell, 2 Tage)
4. Findings dokumentieren und beheben
5. Re-Test nach Fixes

---

## 3. Testing — 100% Abdeckung planen

### Test-Strategie

**Schicht 1: Unit-Tests (vorhanden, erweitern)**
- Pure Funktionen, Utilities, Helper
- Keine DB, keine externen Services
- Ziel: 200+ Tests

**Schicht 2: Integration-Tests (ausbauen)**
- Echte DB (leocrm_test mit Alembic-Migrationen, nicht create_all)
- Echte Redis-Verbindung
- API-Tests über httpx AsyncClient
- LLM gemockt (llm_complete/llm_embed)
- Ziel: 300+ Tests

**Schicht 3: Cross-Module Tests (neu)**
- Plugin A → Contract → Plugin B
- Agent → Tool → DB → Audit
- Workflow → Step → External Service (gemockt)
- Event Bus → Outbox → Consumer
- Ziel: 50+ Tests

**Schicht 4: E2E Tests (Playwright, erweitern)**
- Login → Contact erstellen → Search → Edit → Delete
- Mail: Account → Folder → Message → Attachment
- Agent: Create → Run → Result → Approval
- Workflow: Create → Run → Step → Complete
- Ziel: 30+ Tests

**Schicht 5: Performance Tests (neu)**
- locust/k6: Login, Contact-List, Search unter Last
- 10, 50, 100 gleichzeitige User
- Response-Time < 500ms, Error-Rate < 1%
- Ziel: 10+ Test-Szenarien

### Test-DB Fix (wichtig!)
1. conftest.py umstellen: Alembic-Migrationen statt `Base.metadata.create_all()`
2. RLS-Policies in Test-DB aktivieren
3. Test-Isolation: Jeder Test bekommt clean Schema (TRUNCATE zwischen Tests)
4. Test-Daten-Fixtures: Realistische Test-Daten (Contacts, Companies, Mail, etc.)

### Ablaufplan Testing:
1. Test-DB auf Alembic umstellen (1 Tag)
2. Bestehende Mock-Tests zu Integration-Tests migrieren (3 Tage)
3. Neue Cross-Module Tests schreiben (2 Tage)
4. E2E Tests erweitern (2 Tage)
5. Performance Tests einrichten (1 Tag)
6. CI-Pipeline: Alle Tests müssen grün sein vor Deploy (0.5 Tage)

---

## 4. Monitoring — System Dashboard für Admins

### Backend
1. **Neue Route:** `app/routes/system_dashboard.py`
   - `GET /api/v1/system-dashboard` — Admin-only (`require_permission("system:read")`)
   - Sammelt: Health, DB-Stats, Redis-Stats, Worker-Queue, Active Users, Error-Rate, Response-Times
   - Bei Problemen: `post_system_message()` an internes Nachrichten-System

2. **Monitoring Daten sammeln:**
   - DB: Connection-Pool-Stats, Query-Count, Slow-Queries
   - Redis: Memory, Connections, PubSub Channels
   - Worker: Queue-Length, Failed-Jobs, Running-Jobs
   - App: Active Sessions, Request-Count, Error-Rate
   - Plugins: Active-Status, Health pro Plugin
   - LLM: Cost pro Tag/Agent/Workflow

3. **Alerting:**
   - Wenn Health-Check failed → System-Message an Communication-System
   - Wenn Error-Rate > 5% → System-Message
   - Wenn Worker-Queue > 100 → System-Message
   - Wenn DB-Disk > 80% → System-Message
   - Wenn Redis-Memory > 80% → System-Message

### Frontend
1. **Neue Page:** `frontend/src/pages/SystemDashboard.tsx`
   - Nur für Admins sichtbar (`PermissionRoute permission="system:read"`)
   - Link im linken Menü (Sidebar) — nur für Admins
   - Real-Time Updates (WebSocket oder 30s Polling)
   - Cards: System Health, DB, Redis, Worker, Active Users, Errors, LLM Costs
   - Charts: Response-Time-Trend, Error-Rate-Trend, Queue-Length
   - Alert-Feed: System-Messages aus Communication-System

2. **Sidebar Eintrag:**
   - `{ to: '/system-dashboard', labelKey: 'nav.systemDashboard', icon: <Activity />, order: 95 }`
   - Nur sichtbar wenn `is_system_admin === true`

### Ablaufplan Monitoring:
1. Backend: `system_dashboard.py` Route mit echten DB/Redis/Worker-Stats (1 Tag)
2. Backend: Alerting → System-Message bei Problemen (0.5 Tage)
3. Frontend: `SystemDashboard.tsx` mit Cards und Charts (2 Tage)
4. Frontend: Sidebar-Eintrag + Permission-Check (0.5 Tage)
5. Tests: Integration-Test für Dashboard-Route (0.5 Tage)

---

## 5. Backup — Automatisiert über ARQ Scheduler

### Vorhandene Infrastruktur
- `scripts/backup.py` — Backup-Script (pg_dump + files)
- `scripts/restore.py` — Restore-Script
- ARQ Worker mit cron-Scheduler (vorhanden)
- `scheduler_tick` Job registriert

### Plan
1. **Backup ARQ Job registrieren:**
   - `register_job("auto_backup", auto_backup_job)`
   - Cron-Schedule: Täglich um 03:00 Uhr (einstellbar)
   - Ruft `scripts/backup.py` auf
   - Speichert Backup in `/backups/` (oder S3/Nextcloud)

2. **Settings-Erweiterung:**
   - `backup_enabled: bool = True`
   - `backup_schedule: str = "0 3 * * *"` (cron)
   - `backup_destination: str = "local"` (local/s3/nextcloud)
   - `backup_retention_days: int = 7`
   - In Settings-Page im Frontend einstellbar

3. **Backup-Verifizierung:**
   - Nach jedem Backup: Manifest prüfen (Datei-Anzahl, Größe)
   - Wöchentlich: Test-Restore in Test-DB + Row-Count-Validierung
   - Bei Fehler: System-Message an Communication-System

4. **Restore-Test:**
   - `scripts/restore_test.sh` existiert bereits
   - Als ARQ-Cron-Job: Wöchentlich Restore in Test-DB, Schema validieren

### Ablaufplan Backup:
1. `auto_backup_job` in `app/core/jobs.py` registrieren (0.5 Tage)
2. Settings-Schema erweitern + Frontend-UI (1 Tag)
3. Backup-Verifizierung + Alerting (0.5 Tage)
4. Restore-Test als Cron-Job (0.5 Tage)
5. Tests: Backup erstellen → Restore → Validieren (1 Tag)

---

## 6. Multi-Tenant — RLS Lücken prüfen

### Aktuell
- 113/133 Tabellen haben RLS in Produktion
- 10 Tabellen absichtlich ohne RLS (Auth/System)
- 10 Tabellen brauchen RLS (siehe Punkt 1)

### Weitere Prüfung
1. **ORM Auto-Filter** — Prüfen ob SQLAlchemy automatisch `tenant_id` filtert
2. **Routes ohne Tenant-Check** — Gibt es Routes die `tenant_id` nicht prüfen?
3. **Cross-Tenant Queries** — Gibt es Queries die `tenant_id` nicht filtern?
4. **Plugin-Tables** — Haben alle Plugin-Tables `tenant_id`?
5. **Admin-Bypass** — Können Admins andere Tenants sehen? (Sollten sie nicht)

### Ablaufplan Multi-Tenant:
1. RLS für 10 fehlende Tabellen hinzufügen (Punkt 1) (0.5 Tage)
2. ORM Auto-Filter verifizieren (0.5 Tage)
3. Routes ohne Tenant-Check identifizieren und fixen (1 Tag)
4. Cross-Tenant Integration-Tests schreiben (1 Tag)

---

## 7. Compliance — Geplant in Phase K

Phase K (EU Compliance) ist in der Roadmap geplant mit 6 Tasks:
- AI Use-Case Registry
- Processing Activities Register
- DSR Automation (Access/Erasure/Correction)
- DPIA (Data Protection Impact Assessment)
- AI Act Compliance
- Compliance Reports

Das ist geplant und muss implementiert werden wenn Phase I+J abgeschlossen sind.

---

## 8. Performance Tests

### Plan
1. **locust/k6 Setup** — Load-Testing-Tool installieren
2. **Test-Szenarien:**
   - Login (100 gleichzeitige User)
   - Contact-List (50 User, paginated)
   - Search (50 User, verschiedene Queries)
   - Mail-List (30 User, IMAP-Sync)
   - Agent-Run (10 User, gleichzeitige Agent-Runs)
3. **Metriken:**
   - Response-Time (P50, P95, P99)
   - Error-Rate
   - Throughput (Requests/sec)
   - DB-Query-Count pro Request
   - Redis-Hit-Rate
4. **Baseline messen** — Aktuelle Performance aufzeichnen
5. **Optimierung** — Bottlenecks identifizieren und beheben

### Ablaufplan Performance:
1. locust/k6 installieren + Test-Szenarien schreiben (1 Tag)
2. Baseline messen (0.5 Tage)
3. Bottlenecks identifizieren (0.5 Tage)
4. Optimierung (N+1 Queries, Caching, Indexes) (2 Tage)
5. Re-Test nach Optimierung (0.5 Tage)

---

## 9. Documentation — Anpassen an aktuellen und geplanten Stand

### Was aktualisiert werden muss
1. **README.md** — Aktualisiert ✅ (KI und Business-Plattform)
2. **docs/api-documentation.md** — Alle 468 Routes dokumentieren (aktualisieren)
3. **docs/plugin-development-guide.md** — 23 Plugins dokumentieren (aktualisieren)
4. **docs/infrastructure.md** — Docker, PostgreSQL, Redis, ARQ (aktualisieren)
5. **docs/monitoring.md** — System Dashboard, Alerting (neu schreiben)
6. **docs/security_kernel.md** — RLS, ABAC, Audit, Pen-Test (aktualisieren)
7. **docs/admin-guide.md** — Backup, Restore, Monitoring, Settings (aktualisieren)
8. **docs/deploy-guide.md** — Deploy-Process, Coolify (aktualisieren)
9. **docs/test-strategy.md** — Test-Schichten, Test-DB, CI (aktualisieren)
10. **docs/ui-design-guidelines.md** — System Dashboard, neue Komponenten (aktualisieren)
11. **AGENTS.md** — Build/Test-Commands, Konventionen (aktualisieren)
12. **PROGRESS.md** — Aktueller Stand (aktualisiert ✅)
13. **PLATFORM_ROADMAP.md** — Phasen-Status (aktualisiert ✅)

### Ablaufplan Documentation:
1. Alle Doku-Dateien durchgehen und veraltete Inhalte aktualisieren (2 Tage)
2. Neue Doku für System Dashboard, Backup-Automation, Performance (1 Tag)
3. API-Doku für neue Routes ergänzen (1 Tag)

---

## 10. HA/Scaling — Architektur-Prüfung

### Aktuelle Architektur
- Single-Instance: 1x crm_app, 1x crm_worker, 1x postgres, 1x redis
- Docker-Compose auf einem Hetzner VPS

### Kann die Architektur skalieren?
**Ja, bedingt.** Die Architektur unterstützt Horizontal-Scaling:

1. **crm_app** — Kann horizontal skalieren (stateless, Session in Redis)
   - Mehrere Instanzen hinter Load Balancer (Coolify unterstützt das)
   - WebSocket: Redis PubSub für Multi-Instance (bereits implementiert)
   - Cron-Locks: Bereits implementiert (`_acquire_cron_lock`)

2. **crm_worker** — Kann horizontal skalieren
   - ARQ Worker sind stateless
   - Redis als Queue (bereits implementiert)
   - Cron-Locks verhindern doppelte Ausführung (bereits implementiert)

3. **postgres** — Vertikales Scaling (größerer Server)
   - Für HA: Managed PostgreSQL (z.B. Hetzner Cloud DB, RDS)
   - Read-Replicas für Search-Queries möglich

4. **redis** — Vertikales Scaling
   - Für HA: Redis Sentinel oder Managed Redis

### Was für HA noch fehlt
- Load Balancer (Coolify/Traefik kann das)
- Health-Checks für Auto-Restart (vorhanden)
- Graceful Shutdown (vorhanden)
- Session-Sharing über Redis (vorhanden)

### Fazit: Die Architektur unterstützt HA/Scaling. Bei Bedarf können einfach mehr crm_app und crm_worker Instanzen hinzugefügt werden. PostgreSQL und Redis brauchen dann Managed Services.

### Ablaufplan HA (bei Bedarf):
1. 2-3 crm_app Instanzen hinter Traefik Load Balancer (Coolify)
2. 2 crm_worker Instanzen
3. Managed PostgreSQL (Hetzner Cloud DB oder extern)
4. Managed Redis (oder Redis Sentinel)
5. Keine Code-Änderungen nötig — nur Docker-Compose Anpassung

---

## 11. API Versioning

### Aktuell
- Alle Routes unter `/api/v1/`
- Kein automatisches Versioning

### Plan
- Bei Breaking Changes: Neue Routes unter `/api/v2/`
- Alte Routes bleiben verfügbar (Deprecation)
- Versionierung über URL-Präfix (nicht Header)
- Das ist ausreichend für KMU bis 500 Mitarbeiter

### Fazit: v1 ist ausreichend. Bei v2 einfach neuen Prefix hinzufügen. Keine zusätzliche Infrastruktur nötig.

---

## 12. Rate Limiting — Erklärung

**Was ist Rate Limiting?**
Rate Limiting begrenzt wie viele API-Anfragen ein User in einer bestimmten Zeit machen kann.

**Beispiel:** Ein User kann maximal 100 API-Anfragen pro Minute machen. Wenn er mehr macht, bekommt er einen 429 (Too Many Requests) Fehler.

**Warum wichtig?**
- Schutz vor Missbrauch (Brute-Force, DDoS)
- Faire Ressourcen-Verteilung (ein User kann nicht alle Ressourcen verbrauchen)
- Schutz vor Endlos-Schleifen (z.B. Agent der zu viele LLM-Calls macht)

**Aktuell:**
- Globales Rate-Limiting vorhanden (`GeneralRateLimitMiddleware` in `app/core/rate_limit.py`)
- LLM Cost-Protection vorhanden (Budget-Limits pro Tenant)

**Was fehlt:**
- Per-User Rate-Limiting (nicht nur global)
- Per-Tenant Rate-Limiting
- Spezifische Limits für kritische Endpoints (Login, Password-Reset, Agent-Run)

### Ablaufplan Rate Limiting:
1. Per-User und Per-Tenant Limits in `rate_limit.py` implementieren (1 Tag)
2. Spezifische Limits für Login, Password-Reset, Agent-Run (0.5 Tage)
3. Tests: Rate-Limit wird durchgesetzt (0.5 Tage)

---

## 13. Audit Log — Erklärung

**Was ist Audit Log?**
Audit Log protokolliert jede Änderung am System: Wer hat was wann geändert.

**Beispiel:** "User admin@media-on.de hat Kontakt 'Max Mustermann' um 14:30 Uhr aktualisiert — Feld 'email' geändert von 'alt@example.com' zu 'neu@example.com'"

**Warum wichtig?**
- Nachvollziehbarkeit bei Fehlern
- Compliance (DSGVO fordert Protokollierung)
- Security (wer hat auf welche Daten zugegriffen?)

**Aktuell:**
- `app/models/audit.py` — AuditLog Model vorhanden
- `app/routes/audit.py` — Audit-Log API vorhanden
- `do_action()` feuert bei jeder Änderung
- 81 do_action-Aufrufe im Code

**Was fehlt:**
- **Retention Policy** — Wie lange werden Audit-Logs aufbewahrt? (z.B. 90 Tage, 1 Jahr, 7 Jahre je nach Gesetz)
- **Audit-Log-Export** — Export für Compliance-Prüfung
- **Tamper-Proof** — Audit-Logs sollten nicht löschbar sein (außer durch Admin mit GDPR-Flag)

### Ablaufplan Audit Log:
1. Retention Policy in Settings konfigurierbar (0.5 Tage)
2. ARQ-Cron-Job: Audit-Logs älter als Retention-Period archivieren (0.5 Tage)
3. Audit-Log-Export als CSV/JSON (0.5 Tage)
4. Tamper-Proof: DELETE auf AuditLog nur mit `?gdpr=true` und Admin-Permission (0.5 Tage)

---

## 14. Data Retention — Erklärung

**Was ist Data Retention?**
Data Retention definiert wie lange Daten aufbewahrt werden und wann sie gelöscht werden.

**Beispiel:** "E-Mails werden 7 Jahre aufbewahrt (gesetzliche Pflicht), danach automatisch gelöscht. Gelöschte Kontakte werden 90 Tage im Trash behalten, danach endgültig gelöscht."

**Warum wichtig?**
- Gesetzliche Aufbewahrungspflichten (Handelsrecht, Steuerrecht, DSGVO)
- Speicherplatz-Management
- DSGVO: „Recht auf Vergessenwerden" — Daten müssen löschbar sein

**Aktuell:**
- Soft-Delete mit `deleted_at` vorhanden (alle Entitäten)
- Hard-Delete nur mit `?gdpr=true` (vorhanden)
- Entity History mit Restore vorhanden (Phase D)
- Keine automatische Retention/Löschung nach Zeit

**Was fehlt:**
- Konfigurierbare Retention-Policies pro Datentyp (z.B. Mail=7 Jahre, Contacts=90 Tage Trash)
- ARQ-Cron-Job der abgelaufene Daten archiviert/löscht
- DSGVO-Lösch-Workflow (Betroffenenrechts-Anfragen)

### Ablaufplan Data Retention:
1. Retention-Settings in `config.py` + Settings-Page (0.5 Tage)
2. ARQ-Cron-Job: `cleanup_expired_data` (1 Tag)
3. DSGVO-Lösch-Workflow (in Phase K geplant)
4. Tests: Daten werden nach Retention-Period gelöscht (0.5 Tage)

---

## 15. Incident Response — Erklärung

**Was ist Incident Response?**
Incident Response ist der Plan was passiert wenn etwas schiefgeht (Server-Ausfall, Datenverlust, Security-Breach).

**Beispiel:** „Server ist down → 1. Admin bekommt Alert über System-Dashboard → 2. Backup wird restored → 3. User werden informiert → 4. Post-Mortem wird geschrieben"

**Warum wichtig?**
- Schnelle Reaktion bei Problemen
- Minimierung von Ausfallzeiten
- Dokumentation für Verbesserung

**Aktuell:**
- Health-Check vorhanden (`/api/v1/health`)
- Graceful Shutdown vorhanden
- Error-Logging vorhanden (structlog + trace_id)
- Kein automatisches Alerting
- Kein Runbook

**Was fehlt:**
- **Runbook** — Dokument mit Schritten bei verschiedenen Incident-Typen
- **Alerting** — Automatische Benachrichtigung bei Problemen (über System Dashboard → Communication-System)
- **Post-Mortem Template** — Vorlage für Incident-Dokumentation

### Ablaufplan Incident Response:
1. Runbook schreiben (Server-Ausfall, DB-Crash, Redis-Crash, Security-Breach) (1 Tag)
2. Alerting im System Dashboard implementiert (siehe Punkt 4) (bereits geplant)
3. Post-Mortem Template in `docs/incident-response.md` (0.5 Tage)
4. Recovery-Test: Backup restore + App-Neustart (0.5 Tage)

---

## Zusammenfassung — Alle Ablaufpläne

| # | Bereich | Aufwand | Priorität | Abhängigkeit |
|---|---------|--------|-----------|-------------|
| 1 | RLS für 10 Tabellen | 0.5 Tage | 🔴 Hoch | Keine |
| 2 | Security Audit + Pen-Test | 3.5 Tage | 🔴 Hoch | Nach RLS |
| 3 | Testing 100% | 9.5 Tage | 🔴 Hoch | Nach Test-DB Fix |
| 4 | Monitoring System Dashboard | 4.5 Tage | 🟡 Mittel | Keine |
| 5 | Backup Automation | 3.5 Tage | 🟡 Mittel | ARQ Scheduler |
| 6 | Multi-Tenant Prüfung | 3 Tage | 🔴 Hoch | Nach RLS |
| 7 | Compliance (Phase K) | Geplant | 🟡 Mittel | Nach Phase I+J |
| 8 | Performance Tests | 4.5 Tage | 🟡 Mittel | Nach Testing |
| 9 | Documentation | 4 Tage | 🟡 Mittel | Nach allen Änderungen |
| 10 | HA/Scaling | Bei Bedarf | 🟢 Low | Architektur unterstützt es |
| 11 | API Versioning | v1 ausreichend | 🟢 Low | Keine |
| 12 | Rate Limiting | 2 Tage | 🟡 Mittel | Keine |
| 13 | Audit Log | 2 Tage | 🟡 Mittel | Keine |
| 14 | Data Retention | 2.5 Tage | 🟡 Mittel | ARQ Scheduler |
| 15 | Incident Response | 2.5 Tage | 🟡 Mittel | Nach Monitoring |

**Gesamtaufwand:** ~45 Tage (ohne Compliance, HA, API Versioning)

**Reihenfolge (empfohlen):**
1. RLS (Punkt 1) — 0.5 Tage
2. Test-DB Fix (Teil von Punkt 3) — 1 Tag
3. Multi-Tenant Prüfung (Punkt 6) — 3 Tage
4. Security Audit (Punkt 2) — 3.5 Tage
5. Monitoring (Punkt 4) — 4.5 Tage
6. Testing (Punkt 3) — 9.5 Tage
7. Backup (Punkt 5) — 3.5 Tage
8. Rate Limiting (Punkt 12) — 2 Tage
9. Audit Log (Punkt 13) — 2 Tage
10. Data Retention (Punkt 14) — 2.5 Tage
11. Performance (Punkt 8) — 4.5 Tage
12. Incident Response (Punkt 15) — 2.5 Tage
13. Documentation (Punkt 9) — 4 Tage
14. Compliance (Phase K) — Geplant
15. HA/Scaling (Punkt 10) — Bei Bedarf

---

*Ende des Enterprise-Readiness Plans*