breakpilot-compliance/docs-src/services/sdk-modules/tom.md

TOM — Technische und Organisatorische Massnahmen (Art. 32 DSGVO)

Uebersicht

Das TOM-Modul implementiert die systematische Ableitung, Dokumentation und Ueberpruefung technischer und organisatorischer Massnahmen gemaess Art. 32 DSGVO. Es bietet einen 6-Schritt-Generator-Wizard, eine regelbasierte Kontrollbibliothek mit 88 Massnahmen, Gap-Analyse, SDM-Mapping, auditfaehige Dokumentengenerierung und 11 Compliance-Checks.

Route: /sdk/tom | Backend: backend-compliance:8002 | Checkpoint: CP-TOM

---

Art. 32 DSGVO Anforderungen

Absatz	Anforderung	TOM-Modul Umsetzung
Art. 32 Abs. 1 lit. a	Pseudonymisierung und Verschluesselung	Kategorien ENCRYPTION (5 Controls) und PSEUDONYMIZATION (4 Controls)
Art. 32 Abs. 1 lit. b	Vertraulichkeit, Integritaet, Verfuegbarkeit, Belastbarkeit	8 Kategorien: ACCESS_CONTROL, ADMISSION_CONTROL, ACCESS_AUTHORIZATION, TRANSFER_CONTROL, RESILIENCE, AVAILABILITY, SEPARATION, INPUT_CONTROL
Art. 32 Abs. 1 lit. c	Rasche Wiederherstellung nach Zwischenfall	Kategorie RECOVERY (5 Controls)
Art. 32 Abs. 1 lit. d	Regelmaessige Ueberpruefung und Bewertung	Kategorie REVIEW (11 Controls) + Compliance-Check NO_REVIEW_PROCESS

---

TOM-Ableitung — Zwei Quellen

TOMs werden aus zwei unabhaengigen Quellen abgeleitet:

1. Scope/Profil-Module (Embedded Controls)

Der 6-Schritt-Wizard erfasst:

• CompanyProfile: Branche, Groesse, Rolle (Controller/Processor)
• DataProfile: Datenkategorien, besondere Kategorien (Art. 9), Betroffene
• ArchitectureProfile: Hosting, Cloud-Provider, Mandantenfaehigkeit
• SecurityProfile: Auth, Backup, Logging, DR-Plan
• RiskProfile: CIA-Bewertung, Schutzniveau

Die Rules Engine wertet 88 Embedded Controls gegen die Profile-Daten aus. Jeder Control hat applicabilityConditions mit Operatoren (EQUALS, IN, GREATER_THAN, CONTAINS) und Prioritaeten.

2. Canonical Control Library (CP-CLIB)

Die dynamisch generierte Canonical Control Library (/sdk/control-library) enthaelt unternehmensrelevante Security-Controls aus OWASP, NIST, ENISA und weiteren Frameworks. Diese werden durch den Control Generator Pipeline erzeugt und haben einen eigenen Review-Workflow.

!!! info "Herkunftsdokumentation" Im TOM-Dokument (Sektion 2 und 6) wird die Herkunft jeder Massnahme dokumentiert — ob sie aus der Embedded Control Library oder der Canonical Control Library stammt.

---

Frontend — 5-Tab-Aufbau

Tab	Beschreibung
Uebersicht	Alle TOMs mit Filter (Kategorie, Typ, Status, Applicability), SDM-Abdeckung, Statistiken
Detail-Editor	Einzelne TOM bearbeiten: Status, Verantwortlich, Evidence, Review-Datum
Generator	6-Schritt-Wizard starten, Quick-Stats
Gap-Analyse & Export	Gap-Analyse-Ergebnisse, SDM/Modul-Abdeckung, JSON/DOCX Export
TOM-Dokument	Auditfaehiges HTML-Dokument (12 Sektionen), Org-Header, Revisionsmanager, PDF-Druck

---

Kontrollbibliothek (88 Massnahmen)

Kategorie	Code-Prefix	Anzahl	DSGVO-Referenz
Zutrittskontrolle	TOM-AC	6	Art. 32 Abs. 1 lit. b
Zugangskontrolle	TOM-ADM	6	Art. 32 Abs. 1 lit. b
Zugriffskontrolle	TOM-AZ	7	Art. 32 Abs. 1 lit. b
Weitergabekontrolle	TOM-TR	7	Art. 32 Abs. 1 lit. b
Eingabekontrolle	TOM-IN	5	Art. 32 Abs. 1 lit. b
Auftragskontrolle	TOM-OR	6	Art. 28
Verfuegbarkeit	TOM-AV	7	Art. 32 Abs. 1 lit. b, c
Trennbarkeit	TOM-SE	6	Art. 32 Abs. 1 lit. b
Verschluesselung	TOM-ENC	5	Art. 32 Abs. 1 lit. a
Pseudonymisierung	TOM-PS	4	Art. 32 Abs. 1 lit. a
Belastbarkeit	TOM-RE	5	Art. 32 Abs. 1 lit. b
Wiederherstellbarkeit	TOM-RC	5	Art. 32 Abs. 1 lit. c
Ueberpruefung & Bewertung	TOM-RV / TOM-DL / TOM-TR	11	Art. 32 Abs. 1 lit. d

---

SDM Gewaehrleistungsziele

Das Standard-Datenschutzmodell definiert 7 Gewaehrleistungsziele:

Ziel	Relevante Kategorien
Verfuegbarkeit	AVAILABILITY, RESILIENCE, RECOVERY
Integritaet	ADMISSION_CONTROL, TRANSFER_CONTROL, INPUT_CONTROL, ENCRYPTION, RECOVERY
Vertraulichkeit	ACCESS_CONTROL, ADMISSION_CONTROL, ACCESS_AUTHORIZATION, TRANSFER_CONTROL, ENCRYPTION
Nichtverkettung	ACCESS_AUTHORIZATION, SEPARATION, PSEUDONYMIZATION
Intervenierbarkeit	ORDER_CONTROL, REVIEW
Transparenz	INPUT_CONTROL, ORDER_CONTROL, REVIEW
Datenminimierung	SEPARATION, PSEUDONYMIZATION

!!! tip "SDM-Abdeckung" Die Gap-Analyse (Tab 4) zeigt pro SDM-Gewaehrleistungsziel den Abdeckungsgrad in Prozent. Ziele mit 0% Abdeckung loesen den Compliance-Check UNCOVERED_SDM_GOAL (Schweregrad HIGH) aus.

---

11 Compliance-Checks

#	Check	Schweregrad	Ausloeser
1	MISSING_RESPONSIBLE	MEDIUM	REQUIRED-TOM ohne verantwortliche Person/Abteilung
2	OVERDUE_REVIEW	MEDIUM	TOM mit reviewDate in der Vergangenheit
3	MISSING_EVIDENCE	HIGH	IMPLEMENTED-TOM ohne Evidence (obwohl evidenceRequirements > 0)
4	INCOMPLETE_CATEGORY	HIGH	Kategorie, in der alle REQUIRED-Controls NOT_IMPLEMENTED sind
5	NO_ENCRYPTION_MEASURES	CRITICAL	Kein ENCRYPTION-Control implementiert
6	NO_PSEUDONYMIZATION	MEDIUM	Besondere Datenkategorien (Art. 9) ohne PSEUDONYMIZATION
7	MISSING_AVAILABILITY	HIGH	Kein AVAILABILITY/RECOVERY implementiert + kein DR-Plan
8	NO_REVIEW_PROCESS	MEDIUM	Kein REVIEW-Control implementiert
9	UNCOVERED_SDM_GOAL	HIGH	SDM-Gewaehrleistungsziel mit 0% Abdeckung
10	HIGH_RISK_WITHOUT_MEASURES	CRITICAL	Schutzniveau VERY_HIGH aber < 50% implementiert
11	STALE_NOT_IMPLEMENTED	LOW	REQUIRED-TOM seit > 90 Tagen NOT_IMPLEMENTED

Score-Berechnung: 100 - (CRITICAL*15 + HIGH*10 + MEDIUM*5 + LOW*2), Minimum 0.

---

Backend API (9+ Endpoints)

Methode	Pfad	Beschreibung
GET	/api/v1/tom/state	TOM-Generator-State laden
POST	/api/v1/tom/state	State speichern
POST	/api/v1/tom/evaluate	Controls evaluieren (Rules Engine)
POST	/api/v1/tom/gap-analysis	Gap-Analyse durchfuehren
POST	/api/v1/tom/evidence/upload	Evidence-Dokument hochladen
POST	/api/v1/tom/evidence/analyze	KI-Analyse eines Evidence-Dokuments
POST	/api/v1/tom/export	Export (JSON, DOCX, PDF, ZIP)
GET	/api/v1/tom/controls	Kontrollbibliothek abrufen
GET	/api/v1/tom/controls/:id	Einzelnen Control abrufen

TOM ↔ Canonical Control Mapping API

Methode	Pfad	Beschreibung
POST	/api/compliance/tom-mappings/sync	Controls synchronisieren (Profil-basiert)
GET	/api/compliance/tom-mappings	Alle Mappings auflisten
GET	/api/compliance/tom-mappings/by-tom/{code}	Mappings pro TOM-Kategorie
GET	/api/compliance/tom-mappings/stats	Coverage-Statistiken
POST	/api/compliance/tom-mappings/manual	Manuelle Zuordnung
DELETE	/api/compliance/tom-mappings/{id}	Zuordnung entfernen

!!! info "Proxy-Route (Frontend)" Das Admin-Frontend ruft die Endpoints ueber den Next.js-Proxy auf: /api/sdk/v1/tom/** → backend-compliance:8002/api/v1/tom/** /api/sdk/v1/compliance/tom-mappings/** → backend-compliance:8002/api/compliance/tom-mappings/**

---

TOM-Dokument (12 Sektionen)

#	Sektion	Inhalt
0	Deckblatt	Organisation, DSB, IT-Sicherheit, Version
—	Inhaltsverzeichnis	Automatisch generiert
1	Ziel und Zweck	Art. 32 DSGVO Rechtsrahmen
2	Geltungsbereich	Unternehmen, Hosting, Systeme, Control-Quellen
3	Grundprinzipien Art. 32	Vertraulichkeit, Integritaet, Verfuegbarkeit, Belastbarkeit, Wirksamkeitspruefung
4	Schutzbedarf und Risikoanalyse	CIA-Bewertung, Schutzniveau, DSFA-Pflicht
5	Massnahmen-Uebersicht	Tabelle: Kategorie, Anzahl, Status-Verteilung
6	Detaillierte Massnahmen	Pro Kategorie: Detail-Karten mit Code, Status, Evidence, Mappings
7	SDM Gewaehrleistungsziele	Abdeckungstabelle (7 Ziele x Prozent)
8	Verantwortlichkeiten	Rollenmatrix
9	Pruef- und Revisionszyklus	Review-Zeitplan
10	Compliance-Status	Score, Issues nach Schweregrad
11	Aenderungshistorie	Versionstabelle

Ausgabe: HTML-Download oder PDF-Druck via Browser (window.print()).

---

Drei-Schichten-Architektur (TOM ↔ Canonical Controls)

Die Audit-faehige Dokumentation nutzt eine Drei-Schichten-Architektur:

graph TD
    TOM["TOM-Massnahmen (~88, Audit-Level)"]
    MAP["tom_control_mappings (Bridge-Tabelle)"]
    CC["Canonical Controls (10.000+, Implementation-Level)"]
    TOM --> MAP --> CC

Schicht	Beschreibung	Beispiel
TOM-Massnahmen	88 abstrakte, auditfaehige Massnahmen in 13 Kategorien	TOM-ENC-01: Transportverschluesselung
Mapping-Bridge	Verknuepfung TOM-Kategorie → Canonical Controls per Profil	ENCRYPTION → encryption-Kategorie, Industry-Filter
Canonical Controls	10.000+ konkrete Security-Controls aus OWASP, NIST, ENISA	CRYP-001: Cryptographic Key Lifecycle

Kategorie-Zuordnung

TOM-Kategorie	Canonical Kategorien
ACCESS_CONTROL	authentication, identity, physical
ADMISSION_CONTROL	authentication, identity, system
ACCESS_AUTHORIZATION	authentication, identity
TRANSFER_CONTROL	network, data_protection, encryption
INPUT_CONTROL	application, data_protection
ORDER_CONTROL	supply_chain, compliance
AVAILABILITY	continuity, system
SEPARATION	network, data_protection
ENCRYPTION	encryption
PSEUDONYMIZATION	data_protection, encryption
RESILIENCE	continuity, system
RECOVERY	continuity
REVIEW	compliance, governance, risk

Sync-Algorithmus

1. CompanyProfile (Branche, Groesse) wird gehasht
2. Aenderung erkannt → alte auto-Mappings loeschen
3. Pro TOM-Kategorie: Canonical Controls mit passender category, applicable_industries, applicable_company_size und release_state = 'approved' suchen
4. Neue Mappings inserieren (ON CONFLICT DO NOTHING)
5. Sync-State aktualisieren

---

Cross-Modul-Integration

Modul	Integration
DSFA	TOM-Controls als Massnahmen in Datenschutz-Folgenabschaetzung
VVT	Verknuepfung von TOMs mit Verarbeitungstaetigkeiten
Loeschfristen	Loeschkontrollen (TOM-DL) referenzieren Loeschfristen-Policies
Control Library	Canonical Controls als belegende Security-Controls pro TOM-Kategorie
Risk Assessment	RiskProfile steuert Applicability der Controls

graph LR
    Scope["Scope Engine"] -->|Profile| TOM["TOM (Art. 32)"]
    CLIB["Control Library"] -->|Canonical Controls| TOM
    TOM --> DSFA["DSFA (Art. 35)"]
    TOM --> VVT["VVT (Art. 30)"]
    TOM --> Loeschfristen["Loeschfristen"]
    Risk["Risk Assessment"] -->|RiskProfile| TOM

---

Audit-Faehigkeit

Das TOM-Modul erfuellt 7 Audit-Kriterien:

1. Vollstaendigkeit: 88 Controls decken alle Art. 32 Anforderungen ab
2. Nachvollziehbarkeit: Rules Engine dokumentiert Applicability-Gruende
3. Aktualitaet: Review-Zyklen + Compliance-Check OVERDUE_REVIEW
4. Verantwortlichkeit: Rollenmatrix im TOM-Dokument
5. Evidence: Evidence-Verknuepfung + Gap-Analyse
6. Druckfaehigkeit: Auditfaehiges HTML-Dokument mit 12 Sektionen
7. Wirksamkeitspruefung: 11 Compliance-Checks + Score

---

Datei-Uebersicht

Datei	Beschreibung
admin-compliance/app/sdk/tom/page.tsx	Haupt-Seite mit 5 Tabs
admin-compliance/components/sdk/tom-dashboard/	Tab-Komponenten (Overview, Editor, GapExport, Document)
admin-compliance/lib/sdk/tom-generator/types.ts	Alle TypeScript-Typen
admin-compliance/lib/sdk/tom-generator/controls/loader.ts	88 Embedded Controls
admin-compliance/lib/sdk/tom-generator/rules-engine.ts	Applicability-Auswertung
admin-compliance/lib/sdk/tom-generator/context.tsx	State Management (Reducer)
admin-compliance/lib/sdk/tom-generator/sdm-mapping.ts	SDM-Gewaehrleistungsziel-Mapping
admin-compliance/lib/sdk/tom-compliance.ts	11 Compliance-Checks
admin-compliance/lib/sdk/tom-document.ts	HTML-Dokument-Generator
backend-compliance/compliance/api/tom_mapping_routes.py	TOM ↔ Canonical Control Mapping API (6 Endpoints)
backend-compliance/migrations/068_tom_control_mappings.sql	DB-Schema fuer Mapping-Bridge