Assessment-Baseline und Tiers
Assessment-Baseline und Tiers für Processor: Risikoabstufung, Pflichtfragen und Wiedervorlage statt einmaligem Fragebogen.
Ein einmaliger Fragebogen ist kein Assessment. Ohne Tiers, Pflichtfragen und Wiedervorlage entsteht Theater vor dem Audit: derselbe Chat-SaaS und der Processor mit Lohn- oder Gesundheitsdaten beantworten dieselben Checkboxen, und niemand kann im Folgejahr sagen, welches Restrisiko der Data Owner akzeptiert hat.
Dieser Teil definiert Baseline und Tiers — bevor Subprocessor-Kette, AI-Zusagen und Exit darauf aufsetzen.
Anschluss an Compliance Essentials, Audit-Evidence Operating und Partner-Landschaft.
Vorher: Processor in der Control-Kette. Weiter: Subprocessor-Ketten-Evidenz.
zeptiert hat.
Lösung: Der Data Owner genehmigt ein Tier-Modell mit Kriterien (Datenkategorie, Volumen, Zugriff, Kritikalität), Pflichtmodulen je Tier, datierten Nachweisen, Wiedervorlage-Triggern und getrennten Rollen: Steward führt das Assessment, Custodian prüft technische Claims.
In einem Satz: Kein Processor in den Betrieb ohne genehmigtes Tier, Pflichtmodule, gültige Nachweise und benannte Wiedervorlage.
Entscheidung
Der Data Owner genehmigt ein Tier-Modell:
- Tier-Kriterien (Datenkategorie, Volumen, Zugriff, Kritikalität);
- Pflichtmodule je Tier (Security, Privacy, Continuity, AI falls nötig);
- Nachweise (Report, Zertifikat, Test — mit Gültigkeit);
- Wiedervorlage und Trigger (Incidents, Scope-Change, Subprocessor);
- Steward führt; Custodian prüft technische Claims.
Kein High-Tier-Processor ohne technische Evidence und sichtbares nächstes Review-Datum.
Assessment-Workflow
1. Tier zuweisen
Der Steward schlägt das Tier anhand der Kriterien vor; der Data Owner genehmigt. Artefakt ist ein Decision Record mit Datenkategorie, Volumen, Zugriffsart und Kritikalität — nicht ein Bauchgefühl im Ticket. Der Custodian liefert die technischen Inputs: Admin-Rechte, Residenz, Schnittstellen. Wird dieser Schritt übersprungen, landet jeder Vendor im selben Pack, und High-Risk-Lücken bleiben unsichtbar bis zum Audit.
2. Pack senden und fristen
Das Pflichtmodul-Pack folgt dem genehmigten Tier, nicht einem Einheitsfragebogen. Steward setzt Antwortfrist, Eskalationsweg und einen benannten Vendor-Ansprechpartner. Fehlt die Frist, versandet das Assessment in Inboxen; fehlt die Eskalation, bleibt der Processor ungeprüft im Produktivbetrieb.
3. Claims gegen Evidence prüfen
Steward sammelt Reports, Zertifikate und Tests; Custodian prüft Config-, Log- und Residenz-Claims gegen den laufenden Stack. Screenshots ohne Datum, Zertifikate ohne Scope-Abgleich und „siehe Trust Center“ ohne Snapshot zählen nicht. Ohne diesen Abgleich wird Theater zur Akte: der Ordner ist voll, die Kontrolle leer.
4. Restrisiko entscheiden
Steward legt eine Empfehlung vor (akzeptieren, mitigieren, stoppen) mit offener Lücke und vorgeschlagener Ausnahme. Der Data Owner entscheidet und datiert; eine Ausnahme trägt Freigeber, Grund und Ablauf. Entscheidet niemand namentlich, gilt stillschweigend „weiter so“ — das ist keine Freigabe.
5. Akte und Wiedervorlage
Steward legt die Assessment-Akte ab: Tier, Pack, Evidence, Entscheidung, nächstes Datum, Trigger. Incidents, Scope-Change und neue Subprocessor ziehen die Wiedervorlage vor. Fehlt der Kalendereintrag, ist das Assessment nach Vertragsunterzeichnung tot — genau der Zustand, den dieser Teil verhindert.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| Steward | Vendor | Assessment-Fragebogen + Fristen |
| Vendor | Steward | Nachweise |
| Custodian | Steward | Technische Bewertung |
| Steward | Data Owner | Restrisiko-Empfehlung |
| Steward | Evidence | Assessment-Akte |
Anti-Patterns
- Ein Fragebogen für alle Tiers
- Zertifikate ohne Umfang-Abgleich
- Assessment nur vor Vertragsunterzeichnung
- Keine Wiedervorlage
- Ablehnung vermeiden und alles „mit Ausnahme“ freigeben
Umsetzung im Alltag
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- Drei Tiers mit Kriterien definieren.
- Pflichtmodule für Tier 1 und Tier 2 listen.
- Einen Processor durch das Pack schicken.
- Wiedervorlage-Kalender anlegen.
Vendor and processor assurance
Part 2 of 5
View series