Regulierung & Nachweise

NIS2 und die Cloud: Welche Pflichten beim Anbieter liegen und welche bei dir

Mit dem Betrieb lagerst du Arbeit aus, nicht die Verantwortung. Das Risikomanagement nach dem BSIG umfasst ausdrücklich alle eingesetzten Systeme, und dazu gehören die Cloud-Dienste, die dein Fachverfahren tragen. Was du beim Anbieter einkaufen kannst, sind Nachweise über dessen Teil der Kette. Der Rest, also Konfiguration, Zugriffe, Protokolle und Meldung, bleibt bei dir.

5 Kapitel mit allen Befehlen

Passende Kurse ansehen Persönlich beraten lassen

Einsteigerin in die Cloud-Administration an zwei Monitoren mit Dashboards

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team

Worum es geht

Der Irrtum, mit dem Betrieb auch die Verantwortung auszulagern

Die Zahl der betroffenen Unternehmen steigt in Deutschland um ein Vielfaches. Nach der Gesetzesbegründung wächst der Kreis von rund 4.500 auf etwa 29.500 Einrichtungen. Viele davon haben nie eine Aufsichtsbehörde von innen gesehen und gehen von einer naheliegenden, aber falschen Annahme aus: Wenn der Betrieb beim Hyperscaler liegt, liege dort auch die Pflicht. Das Gegenteil ist der Fall. Der Anbieter fällt als Erbringer von Cloud-Diensten eigenständig unter die Regulierung, und du fällst zusätzlich darunter, sobald dein Sektor und deine Größe es hergeben.

Das Risikomanagement nach Paragraf 30 BSIG bezieht sich auf die Systeme, die deine Dienste tragen, unabhängig davon, wer sie betreibt. Damit gehören die Cloud-Umgebung, ihre Konfiguration, die Zugriffswege und die Sicherungen in deine Betrachtung. Dazu kommt die Lieferkette als eigener Punkt: Du musst begründen können, warum du diesem Anbieter vertraust und welche Unterauftragsverhältnisse dahinterstehen. Ein Logo auf einer Vertriebsseite ist keine Begründung, ein Testat mit passendem Geltungsbereich und passender Region schon.

Am unangenehmsten wird der Fall, in dem der Vorfall beim Anbieter passiert. Deine Meldefristen laufen ab dem Zeitpunkt, an dem du Kenntnis erlangst, nicht ab der Veröffentlichung auf einer Statusseite. Wer erst am zweiten Tag über die Presse davon erfährt, hat die Frühwarnung längst verpasst. Deshalb gehören vertraglich zugesicherte Benachrichtigungswege des Anbieters, benannte Kontakte auf beiden Seiten und ein einmal geprobter Meldeweg zur Pflichtausstattung. Das ist keine Formalie, sondern der einzige Weg, die Fristen überhaupt einhalten zu können.

Miniatur-Szene: Treppe aus drei Stufen hinauf zu einer schwebenden Cloud, Laptop und Wegweiser

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Fünf Pflichten, die auch bei ausgelagertem Betrieb bei dir bleiben

01 Betroffenheit feststellen und die Einrichtung registrieren
02 Cloud-Dienste vollständig im Risikomanagement führen
03 Nachweise des Anbieters prüfen statt nur einsammeln
04 Meldefähigkeit herstellen und den Meldeweg proben
05 Wirksamkeit belegen können, mit Protokollen und Prüfungen
06 Geschäftsleitung einbinden, billigen und schulen lassen

Was du mitnimmst

Was NIS2 im Cloud-Betrieb konkret von dir verlangt

Die Anforderungen lassen sich in fünf Blöcke sortieren, die sich unabhängig voneinander abarbeiten lassen. Vier davon betreffen dich auch dann, wenn der gesamte Betrieb beim Anbieter liegt.

Betroffenheit sauber feststellen

Maßgeblich sind Sektor und Größe. Wesentliche Einrichtungen beginnen bei 250 Beschäftigten oder entsprechenden Umsatz- und Bilanzwerten, wichtige Einrichtungen bereits bei 50 Beschäftigten. Wer selbst unter den Schwellen bleibt, aber wesentliche Einrichtungen beliefert, wird über deren Lieferkettenanforderungen faktisch mitreguliert und sollte dieselben Fragen beantworten können.

Cloud-Dienste in das Risikomanagement holen

Das Risikomanagement umfasst alle Systeme, die deine Dienste tragen. Praktisch heißt das: ein vollständiges Verzeichnis der genutzten Dienste und Regionen, eine Bewertung je Dienst, dokumentierte Maßnahmen und ein Überprüfungsrhythmus. Ein Verzeichnis, das nur die Verträge kennt und nicht die tatsächlich aktivierten Dienste, hält keiner Prüfung stand.

Lieferkette und Verträge belastbar machen

Verlange Testate mit klar benanntem Geltungsbereich, benannte Unterauftragnehmer samt Standorten, zugesicherte Benachrichtigungsfristen bei Vorfällen und einen beschriebenen Ausstiegsprozess. Prüf- und Auditrechte gewähren Hyperscaler in der Regel nicht, dafür braucht es ein vertraglich benanntes Ersatzverfahren über anerkannte Testate. Ohne diese Punkte fehlt dir der Nachweis, nicht dem Anbieter.

Meldewege und Fristen vorbereiten

Nach einem erheblichen Sicherheitsvorfall gilt eine gestufte Meldung: eine erste Frühwarnung innerhalb von 24 Stunden, eine ausführlichere Meldung innerhalb von 72 Stunden und ein Abschlussbericht innerhalb eines Monats. Diese Fristen sind nur einzuhalten, wenn Zuständigkeit, Zugang zur Meldestelle und Textbausteine vorher feststehen und einmal geprobt wurden.

Geschäftsleitung in der Pflicht

Die Geschäftsleitung muss die Risikomanagementmaßnahmen billigen, ihre Umsetzung überwachen und sich regelmäßig schulen lassen. Das ist keine Empfehlung, sondern eine persönliche Pflicht mit Haftungsfolge. Die Bußgeldrahmen reichen bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes für wesentliche Einrichtungen, jeweils der höhere Wert.

Tutorial

Von der Betroffenheitsprüfung bis zur belegbaren Meldefähigkeit

Mit dem Betrieb lagerst du Arbeit aus, nicht die Verantwortung: Konfiguration, Zugriffe, Protokolle und Meldung bleiben bei dir, beim Anbieter kaufst du nur Nachweise über dessen Teil der Kette. Die fünf Blöcke arbeitest du in der Reihenfolge ab, in der sie im Unternehmen anfallen: Betroffenheit klären, die genutzten Cloud-Dienste erfassen, die Nachweise des Anbieters prüfen, die eigenen Belege technisch erzeugen und die Meldefähigkeit herstellen. Die Befehle zeigen AWS und Azure nebeneinander und lesen zunächst nur.

Schritt 1: Betroffenheit und Geltungsbereich klären

Bevor irgendeine Maßnahme sinnvoll ist, brauchst du eine belastbare Einordnung. Sie entscheidet über Aufsichtsregime, Fristen und Bußgeldrahmen.

Einordnung und was daraus folgt

Einordnung	Auslöser	Folge
Besonders wichtige Einrichtung	Sektor der Anlage 1 und mindestens 250 Beschäftigte, oder Jahresumsatz über 50 Mio. Euro und Bilanzsumme über 43 Mio. Euro. Die EU-Richtlinie nennt dieselbe Gruppe wesentliche Einrichtungen	Aufsicht auch ohne Anlass, Bußgeld bis 10 Mio. Euro oder 2 Prozent des weltweiten Jahresumsatzes
Wichtige Einrichtung	Betroffener Sektor und mindestens 50 Beschäftigte oder Umsatz und Bilanzsumme über 10 Mio. Euro	Aufsicht anlassbezogen, Bußgeld bis 7 Mio. Euro oder 1,4 Prozent des weltweiten Jahresumsatzes
Betreiber kritischer Anlagen	Schwellenwerte der Verordnung zur Bestimmung kritischer Anlagen	zusätzliche Anforderungen und regelmäßige Nachweise gegenüber dem BSI
Cloud-Anbieter selbst	Erbringt Cloud-Computing-Dienste, unabhängig von deiner Einstufung	fällt bei Erreichen derselben Größenschwellen eigenständig unter die Regulierung, ersetzt aber deine Pflichten nie
Zulieferer unterhalb der Schwellen	Beliefert betroffene Einrichtungen	wird über deren Lieferkettenanforderungen faktisch mitreguliert, ohne selbst registriert zu sein

Schritt 2: Genutzte Cloud-Dienste vollständig erfassen

Das Verzeichnis, das aus der Vertragsabteilung kommt, ist regelmäßig unvollständig. Belastbar wird es erst, wenn du es gegen die tatsächliche Nutzung in den Konten und Abonnements abgleichst.

Was wird tatsächlich genutzt, und in welchen Regionen?

# AWS: alle Konten der Organisation auflisten
aws organizations list-accounts \
  --query 'Accounts[].{Id:Id,Name:Name,Status:Status}' --output table

# Genutzte Dienste je Region, aus der Abrechnung statt aus der Erinnerung
aws ce get-cost-and-usage --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY --metrics UsageQuantity \
  --group-by Type=DIMENSION,Key=SERVICE Type=DIMENSION,Key=REGION

# Azure: alle Abonnements und Ressourcentypen in einem Durchgang
az account list --query '[].{Name:name,Id:id,State:state}' --output table
az graph query --first 500 -q "Resources
  | summarize anzahl=count() by type, location
  | order by anzahl desc"

Die Auswertung aus der Abrechnung findet auch die Dienste, die einmal jemand ausprobiert hat und die seitdem niemand mehr auf dem Schirm hat. Genau diese Reste sind es, die in Prüfungen auffallen, weil sie in keinem Verzeichnis stehen.

Ordne jedem gefundenen Dienst drei Angaben zu: welches Fachverfahren daran hängt, welche Datenkategorie dort verarbeitet wird und in welcher Region das geschieht. Diese Zuordnung ist der Kern deiner Risikobetrachtung und gleichzeitig die Grundlage für alles Weitere, von der Datenschutz-Folgenabschätzung bis zur Frage, welche Testate du überhaupt brauchst. Für Einrichtungen im Finanzsektor gelten zusätzlich die strengeren Vorgaben der DORA-Verordnung, die deutlich weiter gehen als NIS2. Was dort zusätzlich verlangt wird, steht unter DORA und Cloud-Auslagerung.

Schritt 3: Nachweise des Anbieters prüfen statt einsammeln

Testate werden gern als Anhang zum Vertrag abgelegt und nie gelesen. Der Wert liegt aber im Geltungsbereich, nicht im Deckblatt.

Wo liegen die Daten wirklich?

# AWS: Region je Speicherbereich pruefen, nicht auf Annahmen verlassen
aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' \
  | while read -r b; do
      printf '%s\t%s\n' "$b" \
        "$(aws s3api get-bucket-location --bucket "$b" --query LocationConstraint --output text)"
    done

# Azure: alle Ressourcen ausserhalb der gewuenschten Regionen aufspueren
az graph query --first 500 -q "Resources
  | where location !in ('germanywestcentral','westeurope','northeurope')
  | project name, type, location, subscriptionId"

Regionsangaben in Verträgen und tatsächliche Ablage laufen häufig auseinander, besonders bei Sicherungen, Protokolldaten und Diensten mit globaler Steuerungsebene. Prüfe deshalb getrennt: Nutzdaten, Sicherungen, Protokolle und Metadaten.

Was du vom Cloud-Anbieter verlangst

Aktuelles Testat mit ausgewiesenem Geltungsbereich, nicht nur das LogoEin Testat gilt für bestimmte Dienste in bestimmten Regionen. Nutzt du einen Dienst außerhalb dieses Geltungsbereichs, hast du für ihn keinen Nachweis, obwohl der Anbieter zertifiziert ist.
Typ 2 statt Typ 1 verlangenTyp 1 bestätigt nur, dass Maßnahmen zu einem Stichtag beschrieben waren. Erst Typ 2 prüft die Wirksamkeit über einen Zeitraum, und nur das trägt gegenüber der Aufsicht.
Vertraglich zugesicherte Benachrichtigungsfrist bei VorfällenDeine Frühwarnfrist läuft ab deiner Kenntnis. Erfährst du von einem Vorfall erst über die öffentliche Statusseite, ist ein großer Teil der 24 Stunden bereits verbraucht.
Unterauftragnehmer mit Standorten und Zweck benennen lassenDie Lieferkette endet nicht beim Hyperscaler. Support aus Drittstaaten und weitergereichte Dienste gehören in deine Risikobetrachtung, sonst ist sie unvollständig.
Ausstiegsprozess mit Datenformat, Frist und Entgelt festhaltenOhne beschriebenen und einmal geprobten Ausstieg ist der Anbieterausfall kein steuerbares Risiko, sondern eines, das du erleidest.
Ersatzverfahren für Prüf- und Auditrechte vereinbarenHyperscaler gewähren keine Vor-Ort-Prüfungen. Wenn du das Recht brauchst, brauchst du eine vertraglich benannte Alternative über anerkannte Testate, sonst fehlt der Nachweis in deiner Akte.

Schritt 4: Eigene Belege technisch erzeugen

Wirksamkeit belegt man mit Protokollen, nicht mit Absichtserklärungen. Zwei Dinge müssen stehen: ein lückenloses und unveränderliches Ereignisprotokoll und eine automatische Prüfung der Konfiguration.

Lückenloses Protokoll in beiden Welten

# AWS: alle Regionen, alle Konten, mit Integritaetspruefung
aws cloudtrail create-trail --name org-trail \
  --s3-bucket-name protokoll-eu-2026 \
  --is-multi-region-trail --is-organization-trail \
  --enable-log-file-validation
aws cloudtrail start-logging --name org-trail

# Aufbewahrung technisch erzwingen, damit niemand Belege loeschen kann
# Object Lock setzt aktivierte Versionierung voraus
aws s3api put-bucket-versioning --bucket protokoll-eu-2026 \
  --versioning-configuration Status=Enabled

aws s3api put-object-lock-configuration --bucket protokoll-eu-2026 \
  --object-lock-configuration \
  'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=COMPLIANCE,Days=365}}'

# Azure: Verwaltungs- und Sicherheitsereignisse in einen Arbeitsbereich in der EU
az monitor diagnostic-settings subscription create --name nis2-belege \
  --location germanywestcentral \
  --workspace "$WORKSPACE_ID" \
  --logs '[{"category":"Administrative","enabled":true},
           {"category":"Security","enabled":true},
           {"category":"Policy","enabled":true}]'

Die Aufbewahrungssperre ist der Punkt, an dem aus einem Protokoll ein Beleg wird. Ohne sie kann ein Angreifer mit Administratorrechten genau die Spuren löschen, die du später brauchst, und du kannst nicht belegen, dass er es nicht getan hat. Achtung: Der Modus COMPLIANCE ist unumkehrbar. Die Aufbewahrung laesst sich weder verkuerzen noch aufheben, auch nicht mit Root-Zugang, und der Bucket laesst sich fuer die volle Frist nicht leeren.

Konfiguration automatisch gegen Vorgaben prüfen

# AWS: zentrale Sicht auf Abweichungen ueber alle Konten
aws securityhub enable-security-hub --enable-default-standards
aws configservice put-config-rule --config-rule file://regel-verschluesselung.json
aws configservice describe-compliance-by-config-rule \
  --query 'ComplianceByConfigRules[?Compliance.ComplianceType==`NON_COMPLIANT`].ConfigRuleName'

# Azure: Erfuellungsgrad je Richtlinienzuweisung abrufen
az policy state summarize \
  --management-group mg-produktiv \
  --query 'value[].{Richtlinie:policyAssignmentId,Verstoesse:results.nonCompliantResources}'

Beide Dienste rechnen nach Nutzung ab, Security Hub je Prüfung und je Fund, AWS Config je erfasster Ressource und je Regelauswertung. Über eine ganze Organisation ist das ein dauerhafter Posten, den du vor dem Einschalten überschlägst. Nimm die Ergebnisse monatlich als Momentaufnahme ab und lege sie geordnet ab. Genau diese Reihe von Momentaufnahmen ist der Wirksamkeitsnachweis, den Prüfer sehen wollen. Ein einzelner grüner Bildschirm am Prüfungstag ist wertlos.

Schritt 5: Meldefähig werden und den Weg proben

Die Frühwarnung innerhalb von 24 Stunden gelingt nur, wenn Zuständigkeit, Zugang und Textbausteine vorher feststehen. Alles, was du erst im Ernstfall klärst, kostet dich die Frist.

Zeitleiste eines Vorfalls rekonstruieren

# AWS: wer hat im fraglichen Zeitfenster was getan?
aws cloudtrail lookup-events \
  --start-time 2026-07-20T00:00:00Z --end-time 2026-07-21T00:00:00Z \
  --lookup-attributes AttributeKey=Username,AttributeValue=svc-deploy \
  --query 'Events[].{Zeit:EventTime,Aktion:EventName,Quelle:EventSource}' \
  --output table

# Azure: Verwaltungsereignisse im selben Zeitfenster
az monitor activity-log list \
  --start-time 2026-07-20T00:00:00Z --end-time 2026-07-21T00:00:00Z \
  --query "[].{Zeit:eventTimestamp,Aktion:operationName.value,Wer:caller}" \
  --output table

Übe diese Abfragen einmal ohne Anlass und miss die Zeit. Wer die Zeitleiste eines Vorfalls erst im Ernstfall zusammensucht, verbraucht damit den größten Teil der 24 Stunden für die Frühwarnung.

Zur Meldefähigkeit gehören drei Dinge, die nichts mit Technik zu tun haben: eine benannte Person mit Vertretung, ein eingerichteter Zugang zur Meldestelle des BSI und vorbereitete Textbausteine für Frühwarnung, Meldung und Abschlussbericht. Probe den Weg einmal im Jahr als Übung mit einem erfundenen Vorfall, gemeinsam mit der Geschäftsleitung, denn deren Billigung ist Teil der Pflicht. Wenn du ohnehin ein Testat des Anbieters bewerten musst, lohnt sich zusätzlich der Blick auf das BSI-C5-Testat und darauf, welche Kriterien es tatsächlich abdeckt.

Passende Kurse

Kurse zu Cloud-Sicherheit und NIS2 bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

SC-100 Training: Microsoft Cybersecurity Architect (SC-100T00) 4 Tage Präsenz nächster Termin 02.11.2026 Zum Kurs AZ-500 Training: Microsoft Azure Security Technologies (AZ-500T00-A) 4 Tage Präsenz nächster Termin 05.10.2026 Zum Kurs AWS Security Governance at Scale 1 Tag Präsenz nächster Termin 25.09.2026 Zum Kurs Security Engineering on AWS 3 Tage Präsenz oder Live-Online Termine auf Anfrage Zum Kurs AWS Security Essentials 1 Tag Präsenz nächster Termin 14.10.2026 Zum Kurs

Unverbindlich beraten lassen Alle Azure-Kurse ansehen

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest AZ-500 Quiz - Azure Security Engineer Bereite dich auf die AZ-500 Prüfung vor. Teste dein Wissen zu Azure-Sicherheit, Identity und Netzwerk. Quiz starten

Gut zu wissen

Häufige Fragen zu Cloud-Sicherheit und NIS2

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt

Fällt mein Unternehmen unter NIS2, wenn wir alles in der Cloud betreiben?

Die Betroffenheit hängt an Sektor und Größe, nicht am Betriebsmodell. Ob du im eigenen Rechenzentrum, beim Hoster oder beim Hyperscaler betreibst, ändert nichts an der Einstufung. Was sich ändert, ist die Art der Nachweise: Statt eigener Betriebsdokumentation brauchst du Testate des Anbieters plus Belege für deinen Teil der Konfiguration. Der Cloud-Anbieter selbst fällt zusätzlich und unabhängig von dir unter die Regulierung, weil Cloud-Dienste zu den erfassten digitalen Infrastrukturen gehören. Seine Pflichten ersetzen deine nicht, sie kommen daneben.

Welche Nachweise soll ich vom Anbieter verlangen?

Sinnvoll sind ein C5-Testat vom Typ 2 mit ausgewiesenem Geltungsbereich, eine ISO-27001-Zertifizierung mit passender Erklärung zur Anwendbarkeit und je nach Fall ein SOC-2-Bericht vom Typ 2. Entscheidend ist immer der Geltungsbereich: Welche Dienste, welche Regionen, welcher Zeitraum. Ein Testat, das den von dir genutzten Dienst nicht nennt, hilft dir nicht. Dazu kommen Angaben zu Unterauftragnehmern, Benachrichtigungsfristen bei Vorfällen und ein beschriebener Ausstiegsprozess. Diese Punkte gehören in den Vertrag und nicht in eine Verkaufsunterlage.

Was gilt für die Lieferkette bei Managed Services?

Setzt du einen Dienstleister ein, der seinerseits auf einem Hyperscaler betreibt, hast du zwei Glieder in der Kette und musst beide bewerten. Verlange vom Dienstleister die Offenlegung seiner Unterauftragnehmer, deren Standorte und deren Nachweise. Vertraglich brauchst du eine Weitergabe deiner Anforderungen an diese Kette, insbesondere bei Benachrichtigungsfristen und Ausstieg. Das ist der Punkt, an dem viele Verträge dünn werden, weil der Dienstleister selbst keine strengeren Zusagen hat als die, die er von seinem Anbieter bekommt. Genau das gehört dann in deine Risikobewertung.

Wer meldet, wenn der Vorfall beim Anbieter passiert?

Der Anbieter meldet für seinen eigenen Zuständigkeitsbereich, sofern er selbst reguliert ist. Das entbindet dich nicht: Wenn der Vorfall deine Dienste erheblich beeinträchtigt, bist du meldepflichtig, und deine Fristen laufen ab deiner Kenntnis. Praktisch heißt das, du brauchst vertraglich zugesicherte Benachrichtigungswege mit benannten Kontakten auf beiden Seiten. Verlässt du dich auf die öffentliche Statusseite, erfährst du es zu spät und typischerweise ohne die Angaben, die deine Meldung braucht. Kläre außerdem vorher, welche Informationen der Anbieter im Vorfall überhaupt herausgibt.

Wie belege ich die Wirksamkeit der Maßnahmen?

Mit einer Reihe von Belegen über die Zeit statt mit einer Momentaufnahme. Konkret: unveränderlich abgelegte Ereignisprotokolle über alle Konten und Regionen, monatliche Auswertungen der automatischen Konfigurationsprüfung, dokumentierte Behandlung der gefundenen Abweichungen, Nachweise über durchgeführte Wiederherstellungstests und Protokolle der Schulungen einschließlich der Geschäftsleitung. Dazu die Beschlüsse, mit denen die Geschäftsleitung die Maßnahmen gebilligt hat. Diese Sammlung entsteht nebenbei, wenn die Prozesse laufen, und lässt sich im Nachhinein kaum glaubwürdig herstellen.

Quellen

Zuletzt geprüft am 26. Juli 2026.

Echte Stimmen aus unseren IT-Kursen

“

Sehr kompetent, kurzweilig, hat mich nochmals sehr weitergebracht in meinem täglichen doing.

Rückmeldung aus dem Kurs „AZ-400 Training: Designing and Implementing Microsoft DevOps solutions (AZ-400T00-A)“

“

Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.

Rückmeldung aus dem Kurs „Kubernetes Grundkurs“

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.