# Evidence Type — Code vs. Prozess Controls

## Uebersicht

Nicht jedes Control kann gleich nachgewiesen werden. Ein Verschluesselungs-Control
ist im Quellcode pruefbar, ein Risikomanagement-Control erfordert Dokumente und
Nachweise. Diese Unterscheidung bestimmt, **wie** die Compliance-Plattform den
Nachweis automatisiert oder den Nutzer unterstuetzt.

Das Feld `evidence_type` auf `canonical_controls` klassifiziert jeden Control
in eine von drei Kategorien.

## Die drei Typen

```mermaid
graph LR
    subgraph "code"
        C1["Source Code"]
        C2["IaC / Terraform"]
        C3["CI/CD Pipeline"]
        C4["Cloud Config"]
    end

    subgraph "process"
        P1["Policies"]
        P2["Schulungsnachweise"]
        P3["Vertraege"]
        P4["Screenshots / Audits"]
    end

    subgraph "hybrid"
        H1["Code + Doku"]
        H2["Config + Schulung"]
    end
```

### Code Controls

| Eigenschaft | Beschreibung |
|---|---|
| **evidence_type** | `code` |
| **Nachweis** | Automatisiert pruefbar: Source Code, IaC, CI/CD, Cloud-Konfiguration |
| **Automatisierung** | Hoch — SAST, Dependency Scan, Config Audit |
| **Beispiel-Domains** | SEC, AUTH, CRYPT, NET, LOG, ACC, API |
| **Beispiel** | "AES-256 Verschluesselung at rest" → pruefbar via Code Review / IaC Scan |

### Prozess Controls

| Eigenschaft | Beschreibung |
|---|---|
| **evidence_type** | `process` |
| **Nachweis** | Dokumente, Policies, Schulungsnachweise, Vertraege, Screenshots |
| **Automatisierung** | Gering — erfordert manuelle Uploads oder MCP-Dokumenten-Scan |
| **Beispiel-Domains** | GOV, ORG, COMP, LEGAL, HR, FIN, RISK, AUDIT, ENV |
| **Beispiel** | "Reallabor-Zugang fuer KMUs bereitstellen" → Nachweis ueber Programm-Dokumentation |

!!! info "Governance & Regulatorische Controls"
    Controls wie "Behoerde muss KMUs Zugang zu Reallaboren geben" sind Prozess-Controls.
    Der Nachweis erfolgt ueber Dokumente — nicht im Source Code.
    Auch regulatorische Umsetzungspflichten (GOV-Domain) fallen hierunter.

### Hybrid Controls

| Eigenschaft | Beschreibung |
|---|---|
| **evidence_type** | `hybrid` |
| **Nachweis** | Sowohl Code als auch Dokumente erforderlich |
| **Automatisierung** | Teilweise — Code-Teil automatisiert, Prozess-Teil manuell |
| **Beispiel-Domains** | DATA, AI, INC, IAM |
| **Beispiel** | "MFA implementieren" → Config pruefbar (code) + Nutzer-Schulung noetig (process) |

## Backfill-Heuristik

Der Backfill klassifiziert Controls automatisch anhand des Domain-Prefix:

```
POST /api/compliance/v1/canonical/controls/backfill-evidence-type?dry_run=true
```

**Algorithmus:**

1. Domain-Prefix extrahieren (z.B. `SEC` aus `SEC-042`)
2. Gegen vordefinierte Domain-Sets pruefen (code / process / hybrid)
3. Falls Domain unbekannt: Category als Fallback nutzen
4. Falls auch keine Category: `process` (konservativ)

### Domain-Zuordnung

| Typ | Domains |
|---|---|
| **code** | SEC, AUTH, CRYPT, CRYP, NET, LOG, ACC, APP, SYS, API, WEB, DEV, SDL, PKI, HSM, TEE, TPM, VUL, ... |
| **process** | GOV, ORG, COMP, LEGAL, HR, FIN, RISK, AUDIT, ENV, HLT, TRD, LAB, PHYS, PRIV, DPO, ... |
| **hybrid** | DATA, AI, INC, IAM, OPS, MNT, INT, ... |

## Frontend-Anzeige

In der Control-Library werden Controls mit farbcodierten Badges angezeigt:

| evidence_type | Badge | Farbe | Bedeutung |
|---|---|---|---|
| `code` | **Code** | Blau (sky) | Technisch, im Source Code pruefbar |
| `process` | **Prozess** | Amber/Orange | Organisatorisch, Dokument-basiert |
| `hybrid` | **Hybrid** | Violett | Beides erforderlich |

Zusaetzlich steht ein Dropdown-Filter "Nachweisart" zur Verfuegung.

## Zusammenspiel mit anderen Feldern

| Feld | Zweck | Beispiel |
|---|---|---|
| `evidence_type` | **WAS** wird nachgewiesen (Code oder Prozess) | `code` |
| `verification_method` | **WIE** wird verifiziert | `code_review`, `document`, `tool`, `hybrid` |
| `evidence_confidence` | **WIE SICHER** ist der Nachweis (0.0 - 1.0) | `0.92` |
| `normative_strength` | **WIE VERBINDLICH** ist das Control | `must`, `should`, `may` |

!!! warning "evidence_type vs. verification_method"
    `evidence_type` sagt, ob ein Control technisch oder organisatorisch ist.
    `verification_method` sagt, mit welcher Methode es geprueft wird.
    Ein `process`-Control kann trotzdem `verification_method = tool` haben
    (z.B. wenn ein MCP-Scan Dokumente automatisch prueft).

## Kuenftige Automatisierung

### Code Controls
- **Git-Repository-Scan**: SAST, Secret Detection, Dependency Check
- **IaC-Analyse**: Terraform/Pulumi/CloudFormation Policies
- **CI/CD-Integration**: Pipeline-Ergebnisse als Evidence sammeln

### Prozess Controls
- **MCP-Dokumenten-Scan**: Kunden-Laufwerk anbinden, Dokumente automatisch pruefen
- **Screenshot-Analyse**: OCR + LLM-Validierung von Screenshots
- **Interview-Protokolle**: Strukturierte Audit-Checklisten
