Custodian und Control Owner unterscheiden

Der Custodian betreibt technische Schutzmaßnahmen und Datenservices. Der Control Owner verantwortet Design, Angemessenheit und Wirksamkeit einer Kontrolle. Zusammenarbeit ist eng; Accountability bleibt je Entscheidung eindeutig.

← Vorheriger Teil · Nächster Teil →

Die Verwechslung entsteht leicht: Wer eine Zugriffsliste pflegt, kennt die Kontrolle am besten. Daraus folgt aber nicht, dass dieselbe Person auch entscheiden sollte, ob die Kontrolle das Risiko angemessen reduziert und wirksam arbeitet. Betrieb erzeugt Evidenz; Control Verantwortung bewertet sie gegen ein definiertes Ziel. Werden beide Hüte unsichtbar zusammengelegt, wird aus „der Job lief erfolgreich“ schnell die unbelegte Aussage „die Kontrolle ist wirksam“.

zmaßnahmen und Datenservices. Der Control Owner verantwortet Design, Angemessenheit und Wirksamkeit einer Kontrolle. Zusammenarbeit ist eng; Accountability bleibt je Entscheidung eindeutig.

Lösung: Trennt mindestens drei Entscheidungen: technische Umsetzung, Freigabe des Kontrolldesigns und Bewertung der Wirksamkeit.

In einem Satz: Trennt mindestens drei Entscheidungen: technische Umsetzung, Freigabe des Kontrolldesigns und Bewertung der Wirksamkeit.

Entscheidung

Trennt mindestens drei Entscheidungen: technische Umsetzung, Freigabe des Kontrolldesigns und Bewertung der Wirksamkeit. Bei niedrigem Risiko kann eine Person mehrere Hüte tragen; Selbstprüfung wird transparent gemacht und risikobasiert kompensiert.

Der Custodian ist für die verlässliche technische Realität verantwortlich: Konfiguration, Betrieb, Monitoring, Wiederherstellung, Logging und sichere Ausführung. Er entscheidet innerhalb technischer Leitplanken, wie eine freigegebene Anforderung umgesetzt wird. Der Control Owner entscheidet, welches Risiko adressiert wird, wie die Kontrolle gestaltet sein muss, welche Evidenz genügt, wie Ausnahmen behandelt werden und ob das verbleibende Risiko akzeptabel ist. Eine Assurance- oder Testrolle prüft bei höherem Risiko unabhängig, ob Design und Betrieb tatsächlich wirksam sind.

Diese Trennung ist eine Entscheidungstrennung, keine pauschale organisatorische Mauer. In einem kleinen Unternehmen können dieselben Personen mehrere Hüte tragen. Dann müssen Zeitpunkt, Mandat und Kompensation sichtbar sein: etwa unabhängige Stichprobe, Sponsor-Review, externer Test oder nachgelagerte Kontrolle. Ein A je Entscheidung bleibt die Grundregel.

Vier Fragen für jede Kontrolle

1. Welches konkrete Risiko soll auf welches Niveau reduziert werden?
2. Wer darf Design und Schwellenwerte verbindlich freigeben?
3. Wer implementiert und betreibt die Maßnahme?
4. Wer bewertet mit welcher Evidenz und Unabhängigkeit die Wirksamkeit?

Fehlt eine Antwort, ist die Kontrolle entweder nicht steuerbar oder nicht prüfbar. Ein Tool-Screenshot allein beantwortet keine dieser Fragen.

Durchgearbeitetes Beispiel: privilegierter Zugriff

Ein E-Commerce-Unternehmen verwaltet sein Customer-360-Warehouse. Zwölf Engineers besitzen Produktionszugriff; vier davon dürfen Rollen vergeben. Die Plattformleiterin ist als „Owner Access Control“ dokumentiert. Sie genehmigt Anträge, administriert Rollen und bestätigt im Quartal selbst, dass die Kontrolle funktioniert. Nach einem Rollenwechsel behält ein ehemaliger Team Lead drei Monate lang Adminrechte. Der Quartalstest meldet trotzdem „bestanden“, weil der Export technisch erzeugt wurde.

Das Team zerlegt den Ablauf:

• Kontrolldesign freigeben: A ist der Security kontrollverantwortliche Person. Das Design verlangt zeitlich begrenzte Adminrollen, Genehmigung durch fachlichen Vorgesetzten und Data Owner, monatliche Rezertifizierung sowie sofortigen Entzug bei Offboarding.
• Zugriff technisch umsetzen: A für den Zugriffsverwaltung-Servicebetrieb ist der technischer Betreiber; ein Zugriffsverwaltung Engineer ist R. Er implementiert Rollen, Ablaufdatum, Logs und Entzug.
• Einzelnen fachlichen Zugriff genehmigen: A ist der mandatierte Access Approver für den Datenprodukt-Umfang. Security und Data Owner sind je nach Sensitivität C.
• Wirksamkeit bewerten: A ist der kontrollverantwortliche Person; bei privilegiertem Zugriff führt Internal Assurance den Test als unabhängiges R aus.

Das Evidenzpaket enthält nicht nur einen erfolgreichen Job. Es enthält Population aller privilegierten Konten, Stichprobenlogik, Genehmigung, Ablaufdatum, Joiner-Mover-Leaver-Abgleich, gefundene Abweichungen und deren Behandlung. Die drei Monate alte Berechtigung wird als Kontrollfehler klassifiziert. Der Custodian entzieht sie sofort; der Control Owner entscheidet zusätzlich, dass HR-Ereignisse innerhalb von vier Stunden in IAM verarbeitet und Kontrollfehler nach fünf Arbeitstagen eskaliert werden.

Die Rollen arbeiten eng zusammen, aber niemand bewertet lediglich die eigene Ausführung. Der Business/Data Owner entscheidet über zulässigen fachlichen Zugriff; der Control Owner über das Sicherheitsdesign; der Custodian über sichere technische Umsetzung. Die Abgrenzung zur fachlichen Owner-Rolle wird in Verantwortung ist Entscheidungsrecht erläutert.

Sizing: proportionale Trennung

SMB

Bei wenigen Mitarbeitenden kann der IT Lead Custodian und Control Owner sein. Markiert diese Kombination ausdrücklich. Für hohe Risiken wie Produktionsadmin, Zahlungsdaten oder Massendownloads prüft Geschäftsleitung, externer Dienstleister oder eine unabhängige Person mindestens stichprobenartig. Automatisierte Reports reduzieren Aufwand, ersetzen aber keine Bewertung. Konzentriert euch auf fünf kritische Kontrollen statt auf ein umfangreiches Kontrollregister.

Mid-Market

Benennt Control Owner nach Risikobereich und Custodians nach Service. Trennt mindestens Implementierung und periodischen Test. Nutzt standardisierte Evidenzvorlagen, Fehlerschwellen und Ausnahmefristen. Ein monatliches Forum behandelt nur gescheiterte Tests, überfällige Maßnahmen und Restrisiken. Der Control Owner muss Ressourcen eskalieren können; andernfalls bleibt er nur Dokumentationsstelle.

Enterprise

Definiert formale Segregation of Duties für Hochrisikokontrollen. First Line betreibt, Control Owner steuert Design und Bewertung, unabhängige Assurance prüft risikobasiert. Verknüpft Kontrollkatalog, Assets, Risiken, Testpläne und Findings. Delegierte Control Owner brauchen klare Scopes; zentrale Standards dürfen lokale Accountability nicht unkenntlich machen. Automatisierung muss Population, Vollständigkeit und Manipulationsschutz nachweisen.

Workflow

1. Kontrollen inventarisieren. Startet mit tatsächlichen Zugriffen, Changes und Incidents, nicht nur mit Richtliniennamen.
2. Risiko und Ziel festlegen. Beschreibt unerwünschtes Ereignis, Schutzobjekt, Toleranz und relevante Verpflichtung.
3. Entscheidungen schneiden. Trennt Designfreigabe, technische Umsetzung, laufenden Betrieb, Einzelgenehmigung, Test und Ausnahme.
4. Je Entscheidung ein A setzen. Prüft Mandat und Konsequenzrecht, nicht den historischen Titel.
5. Mehrfachhüte markieren. Dokumentiert Selbstgenehmigung, Selbstprüfung und Zugriff auf manipulierbare Evidenz.
6. Evidenz spezifizieren. Definiert Population, Zeitraum, Quelle, Prüfschritt, erwartetes Resultat und Aufbewahrung.
7. Ausnahmen gestalten. Jede Ausnahme braucht Begründung, kompensierende Maßnahme, Ablaufdatum und accountable Genehmigung.
8. Fehler behandeln. Unterscheidet einmalige Abweichung, Designfehler und systemisches Versagen; setzt Frist und Eskalation.
9. Szenario testen. Simuliert Rollenwechsel, Notfallzugriff, fehlgeschlagenen Job und manipulierte Stichprobe.
10. Review terminieren. Passt Frequenz und Unabhängigkeit an Risiko und Fehlersignale an.

Handoffs

„Bestanden“ ohne Population und Testschritt ist keine verwertbare Übergabe. Ebenso darf der Control Owner technische Rohdaten nicht ungeprüft als Schlussfolgerung weiterreichen.

Anti-Patterns

• Der Operator prüft sich selbst: Ein erfolgreicher Lauf wird mit Wirksamkeit verwechselt.
• kontrollverantwortliche Person betreibt alles: Die Rolle verliert Distanz und wird zum Engpass.
• Tool gleich Kontrolle: Der Kauf eines Zugriffsverwaltung- oder DLP-Systems wird als Risikoreduktion gewertet.
• Screenshot als Evidenz: Zeitpunkt, Grundgesamtheit und Vollständigkeit fehlen.
• Keine Evidenz bedeutet bestanden: Fehlende Daten werden nicht als Fehler eskaliert.
• Ausnahme ohne Ablauf: Temporärer Adminzugriff wird dauerhaft.
• Vier-Augen-Prinzip für alles: Niedrigrisikofälle werden unnötig langsam, kritische Fälle gehen in Masse unter.
• Titel statt Entscheidung: „Security ist zuständig“ beantwortet weder Design- noch Testfrage.
• Finding beim technischer Betreiber parken: Das technische Team soll Restrisiko akzeptieren, obwohl ihm das Mandat fehlt.

Checkliste

• Risiko, Schutzobjekt und Kontrollziel sind konkret.
• Design, Betrieb, Genehmigung und Test sind getrennte Entscheidungen.
• Jede Entscheidung hat genau ein A.
• technischer Betreiber und kontrollverantwortliche Person kennen ihre ausgeschlossenen Rechte.
• Mehrfachhüte und Selbstprüfung sind sichtbar klassifiziert.
• Hochrisikotests besitzen angemessene Unabhängigkeit.
• Evidenz nennt Grundgesamtheit, Zeitraum, Quelle und erwartetes Ergebnis.
• Fehlende Evidenz wird als Abweichung behandelt.
• Ausnahmen haben Begründung, Kompensation und Ablaufdatum.
• Findings besitzen verantwortliche Person, Frist und Eskalation.
• Stellvertretungen können auf Systeme und Records zugreifen.
• Reviewfrequenz folgt Risiko und Fehlersignalen.

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.

• Arbeitsplan — Governance Foundations
• Lernpfad — Governance Foundations

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.

Wählt in Woche 1 fünf Kontrollen mit realen Konsequenzen, etwa Adminzugriff, Datenexport, Produktionschange, Backup-Restore und Offboarding. Trennt in Woche 2 Design, Betrieb und Test; markiert Mehrfachhüte und fehlende Evidenz. Definiert in Woche 3 für jede Kontrolle ein minimales Evidenzpaket und einen Ausnahmeweg. Testet in Woche 4 den höchsten Konflikt mit einem realen Sample und behebt mindestens eine konkrete Abweichung. Veröffentlicht keine perfekte Matrix, sondern belastbare Verantwortungen für diese fünf Fälle.

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.

• Arbeitsplan — Governance Foundations
• Lernpfad — Governance Foundations

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.

Bis Tag 60 übertragt ihr das Muster auf die wichtigsten Services und vereinheitlicht Testvorlagen, Schweregrade und Maßnahmenfristen. Verknüpft Findings mit Changes und Incidents. Prüft, ob automatische Evidenz vollständig, unverändert und reproduzierbar ist.

Bis Tag 90 sind Hochrisikokontrollen unabhängig getestet, Ausnahmen mit Ablauf versehen und Delegationen dokumentiert. Ein quartalsweises Review betrachtet wiederkehrende Fehler, überfällige Findings und unangemessene Selbstprüfung. SMBs nutzen externe Stichproben, Mid-Market trennt organisatorisch, Enterprises etablieren formale Assurance. Reife zeigt sich an nachvollziehbaren Entscheidungen, nicht an der Zahl der Kontrollen.

Verwandte Playbooks

• Roles Hub – Rollenmandate und Grenzen.
• Verantwortung finden und aktivieren – accountable Role Holder einsetzen.
• Verantwortung ist Entscheidungsrecht – Fachentscheidung und technische Umsetzung trennen.
• Ein A je Entscheidung – RACI sauber schneiden.
• Mehrfachhüte und Konflikte – Selbstgenehmigung proportional behandeln.