Teamstudie: DORA im Team

Was diese Teamstudie Ihrem Team gibt

DORA-Anforderungen im Team durcharbeiten – mit Rollenverteilung und konkreten nächsten Schritten.

DORA im Team

Warum Regulierungsprojekte an Teamdynamik scheitern – und wie sie gelingen

Unternehmen	Crediva Systems AG, Luzern
Branche	ICT-Dienstleister für EU-Finanzkunden
Grösse	ca. 40 Mitarbeitende
Regulierung	DORA (Digital Operational Resilience Act)
Kernfrage	Warum scheitern fachlich kompetente Teams an Governance-Projekten?
Lernpunkt	Nicht Fachwissen fehlt – sondern eine gemeinsame Verarbeitungsstruktur

Einordnung

Diese Teamstudie zeigt exemplarisch, dass die Umsetzung von DORA in der Praxis nicht an Technik oder fehlendem Fachwissen scheitert, sondern häufig an ungeklärten Rollen, unausgesprochenen Erwartungen und nicht abgestimmten Arbeitslogiken im Team.

Die Ausgangslage

Die Crediva Systems AG mit Sitz in Luzern ist ein technologieorientiertes KMU, das als ICT-Dienstleister für EU-Finanzkunden tätig ist. Technisch ist das Unternehmen gut aufgestellt. Die Systeme sind stabil, die Mitarbeitenden erfahren, die Kunden zufrieden.

Mit Beginn der DORA-Vorbereitungen zeigt sich jedoch schnell: Die grössten Reibungen entstehen nicht in der Architektur – sondern im Team. Vier Menschen, vier Logiken, ein Raum.

Das Modell: Vier Arbeitslogiken

Der externe CISO bringt ein einfaches, aber wirkungsvolles Modell mit: Jeder Mensch filtert Informationen durch eine dominante Arbeitslogik. In Governance-Projekten prallen diese Logiken oft unproduktiv aufeinander – nicht weil die Menschen schwierig sind, sondern weil niemand die Unterschiede benennt und nutzt.

System	Arbeitslogik	Fokus	In diesem Meeting
A	Resonanz	Menschen, Klima, Wirkung	Elena – CEO
B	Struktur	Pflichten, Relevanz, Entscheidungen	Maja – Head of Legal
C	Exploration	Ideen, Optionen, Innovation	Nele – Senior Developer
D	Tiefe	Analyse, Risiken, Abhängigkeiten	Marc – IT-Leitung

Seine Kernaussage: DORA verlangt, dass all diese Perspektiven integriert werden – aber nicht gleichzeitig. Koordinierte Abfolge erzeugt Wirksamkeit. Unkoordinierte Gleichzeitigkeit erzeugt Konflikte.

Der erste DORA-Workshop

Im ersten internen Risikoworkshop stellt Marc, Leiter IT-Operations, ein neues Logging- und Monitoring-Konzept vor. Es ist durchdacht, technisch sauber und auf Skalierbarkeit ausgelegt.

Noch bevor er seine Ausführungen abschliessen kann, meldet sich Nele, Senior Entwicklerin:

„Das könnte man noch ganz anders denken – wir könnten zusätzlich …“

Marc unterbricht sie. Maja verdreht sichtbar die Augen. Elena spürt, wie die Spannung im Raum steigt. Der CISO beobachtet – und sagt zunächst nichts.

Das Meeting wird zäh. Manche fühlen sich ausgebremst, andere übergangen. Es liegt kein Sachproblem vor. Es liegt ein Verarbeitungs- und Abstimmungsproblem vor.

Vier Perspektiven – ein Raum

System A – Resonanz

Elena

„Wie bleiben wir als Organisation handlungsfähig, ohne uns intern zu zerreiben?“

System B – Struktur

Maja

„Was ist das konkrete Ergebnis – und was bedeutet das regulatorisch?“

System C – Exploration

Nele

„Warum reden wir über Einschränkungen, bevor wir überhaupt gedacht haben?“

System D – Tiefe

Marc

„Lasst mich bitte einen Gedanken einmal zu Ende führen.“

Die Intervention des CISO

Nach zwanzig Minuten unterbricht der externe CISO das Meeting. Er stellt keine Fragen. Er macht keine Vorwürfe. Er benennt sachlich, was er beobachtet:

„Wir haben kein fachliches Problem. Wir haben ein Problem der gleichzeitigen Verarbeitung unterschiedlicher Perspektiven. Alle vier haben recht – aber nicht zur gleichen Zeit.“

Er skizziert die vier Arbeitslogiken an der Tafel. Plötzlich schauen die Beteiligten nicht mehr feindselig, sondern interessiert. Die Spannung lässt nach – nicht weil das Problem gelöst ist, sondern weil es einen Namen hat.

Die strukturierte Meeting-Logik: C → D → B → A

Der CISO schlägt vor, künftige DORA-Arbeit strikt in Phasen zu strukturieren. Die Reihenfolge ist nicht beliebig: Sie folgt der Logik, wie Ideen reifen.

Phase 1 — Exploration (System C)

Keine Bewertung. Keine Einwände. Kein Rechtfertigen. Nele darf beginnen. Sie erklärt, was sie am Logging-Konzept interessant findet und welche Erweiterungen sie sieht. Niemand unterbricht. Marc notiert still. Maja hört zu. Nach fünf Minuten hat der Raum eine andere Energie. Nele fühlt sich gehört. Marc realisiert, dass ihre Ideen sein Konzept nicht zerstören, sondern ergänzen.

Phase 2 — Analyse (System D)

Machbarkeit, Risiken, Abhängigkeiten – ohne Entscheidung. Marc legt nun das Konzept vollständig dar. Niemand unterbricht. Er erklärt die Abhängigkeiten, die nur Sinn ergeben, wenn man das Gesamtbild kennt. Am Ende stellt er selbst fest: Neles Ideen aus Phase 1 lassen sich in drei Punkte seines Konzepts integrieren – ohne es zu schwächen.

Phase 3 — Struktur (System B)

Pflichten klären, Prioritäten setzen, Entscheidungen formulieren. Maja ordnet. Nicht als Bremse, sondern als Architektin. Sie formuliert, welche Teile des Konzepts DORA-Pflicht sind, welche Best Practice und welche optional. Sie schlägt eine Priorisierung vor: was sofort, was in sechs Monaten, was optional. Marc bestätigt die technische Umsetzbarkeit.

Phase 4 — Kommunikation (System A)

Erwartungen, Verantwortlichkeiten, Informationswege. Elena fasst zusammen – nicht das technische Detail, sondern das Gemeinsame: Was haben wir heute entschieden? Wer trägt was? Wie informieren wir die restliche Organisation? Sie formuliert eine Kernaussage: „DORA ist kein IT-Projekt. DORA ist ein Management- und Steuerungsrahmen. Und er gelingt nur, wenn wir alle vier Perspektiven brauchen.“

Die Wirkung

In den folgenden Workshops verändert sich die Dynamik spürbar. Das Team arbeitet nicht gegen-, sondern miteinander.

Ideen haben Raum – aber zur richtigen Zeit

Risiken werden gründlich analysiert – ohne zu blockieren

Entscheidungen werden klar getroffen und dokumentiert

Kommunikation wird bewusst geführt statt implizit angenommen

Am Ende entsteht nicht nur eine belastbare DORA-Architektur, sondern auch ein Team, das effektiver zusammenarbeitet – weit über DORA hinaus.

Learnings

1	DORA scheitert selten an Technik	Die grössten Risiken liegen in ungeklärten Rollen, impliziten Annahmen und ungeordneten Entscheidungsprozessen.
2	Perspektiven sind eine Ressource	Unterschiedliche Arbeitslogiken sind kein Problem – sie sind ein Vorteil, wenn sie strukturiert integriert werden.
3	Reihenfolge ist entscheidend	C → D → B → A: Unkoordinierte Gleichzeitigkeit erzeugt Konflikte. Strukturierte Abfolge erzeugt Wirksamkeit.
4	Führung verbindet	Erfolgreiche DORA-Umsetzung braucht Führung, die Perspektiven anerkennt, Prozesse strukturiert und Verantwortung klar zuweist.
5	Das Modell funktioniert über DORA hinaus	Die 4-Phasen-Logik ist kein DORA-Tool. Sie ist eine allgemeine Methodik für komplexe Governance-Entscheidungen unter Zeitdruck.

Kernaussage

DORA ist nicht nur Regulierung. DORA ist Organisations- und Teamentwicklung. Wer das versteht, hat nicht nur bessere Compliance-Projekte – sondern ein besseres Unternehmen.

NBK Legal ·

Die vorliegende Teamstudie ersetzt keine Rechtsberatung.

Weiter vertiefen

Leitfaden Leitfaden DORA DORA als Vorbereitung lesen. Lesen → Self-Check Self-Check DORA Individuelle DORA-Readiness prüfen. Lesen → Fallstudie Fallstudie DORA DORA-Umsetzung in der Praxis. Lesen →