Im Rahmen von NIS2 ist der Umgang mit Schwachstellen Teil der Maßnahmen zum Cybersicherheits-Risikomanagement, die die betroffenen Unternehmen ergreifen müssen. Art. 21 Abs. 2 Buchst. e betrifft die Sicherheit beim Erwerb, bei der Entwicklung und bei der Wartung von Netz- und Informationssystemen, einschließlich des Umgangs mit Schwachstellen und deren Offenlegung. Organisatorische Verpflichtungen ergeben sich aus den nationalen Umsetzungsvorschriften und – für die betroffenen Anbieter – aus unmittelbar geltenden EU-Verordnungen. Dieser Leitfaden erläutert die relevanten Anforderungen, einen praktischen Arbeitsablauf und eine Checkliste für Nachweise, einschließlich des deutschen rechtlichen Kontexts. NIS2 Artikel 21
Allgemeine Informationen, keine Rechtsberatung. Überprüfen Sie den Geltungsbereich, die Einstufung und die Verpflichtungen im Hinblick auf die geltenden EU-Vorschriften, die nationalen Umsetzungsvorschriften und qualifizierte Beratung.
Was bedeutet Schwachstellenmanagement im Rahmen von NIS2?
NIS2 definiert kein einheitliches „Programm zum Schwachstellenmanagement“. Darin wird die Verpflichtung festgelegt, angemessene und verhältnismäßige Maßnahmen zum Risikomanagement zu ergreifen, wobei der Umgang mit Schwachstellen als eines der genannten Elemente genannt wird. In der Praxis wird dies in einem fundierten Ansatz als kontinuierlicher Lifecycle betrachtet: Erkennen, Klassifizieren, Priorisieren, Beheben oder Mindern, Überprüfen und Dokumentieren.
Das Ziel besteht darin, ausnutzbare Schwachstellen in Ihren Systemen zu finden und zu beheben, bevor sie Schaden anrichten – und zwar so, dass Sie dies im Nachhinein erklären und belegen können.
Welche NIS2-Anforderungen beziehen sich auf Schwachstellen?
In mehreren Abschnitten der Richtlinie werden Schwachstellen behandelt. Halten Sie sie voneinander getrennt:
- Artikel 21 Absatz 2 Buchstabe e: Sicherheit bei der Beschaffung, Entwicklung und Wartung von Netzwerk- und Informationssystemen, einschließlich des Umgangs mit Schwachstellen und deren Offenlegung. Dies ist die zentrale Bestimmung. Artikel 21 Absatz 2 Buchstabe e
- Artikel 21 im weiteren Sinne: Zu dieser Liste gehören unter anderem Richtlinien zur Risikoanalyse, das Vorfallmanagement, die Sicherheit der Lieferkette sowie Maßnahmen zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen.
- Artikel 12: Koordinierte Offenlegung von Schwachstellen. Die Mitgliedstaaten benennen ein Team zur Reaktion auf Computersicherheitsvorfälle (CSIRT) als Koordinator, und die ENISA unterhält eine europäische Schwachstellendatenbank. Unternehmen können sich mit Anbietern und Berichterstattern abstimmen und dabei bei Bedarf auf die Unterstützung des CSIRT zurückgreifen. Artikel 12
- Artikel 20: Verwaltungsorgane müssen die Umsetzung von Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen und überwachen sowie entsprechende Schulungen durchführen. Sie können vorbehaltlich der geltenden Rechtsvorschriften für Verstöße haftbar gemacht werden. Artikel 20
- Artikel 23: Die Meldung schwerwiegender Vorfälle ist eine von der Schwachstellenbehebung getrennte Verpflichtung. Die Feststellung einer Schwachstelle ist nicht automatisch ein meldepflichtiger schwerwiegender Vorfall; Vorfälle sind anhand der geltenden Schweregradkriterien zu bewerten. Artikel 23
Die Durchführungsverordnung (EU) 2024/2690 der Kommission legt verbindliche technische und methodische Anforderungen für die betroffenen DNS-Anbieter, TLD-Registrien, Cloud- und Rechenzentrumsanbieter, Content-Delivery-Netzwerke, MSPs, MSSPs, Online-Marktplätze, Suchmaschinen, Plattformen für soziale Netzwerke und Vertrauensdienstleister fest. Dies gilt nicht für alle Unternehmen, die unter NIS2 fallen. In Anhang 6.6 wird das Sicherheits-Patch-Management behandelt, und in Anhang 6.10 geht es um den Umgang mit Schwachstellen und deren Offenlegung. Verordnung 2024/2690
Betriebliche Anforderungen für betroffene Anbieter
Für Anbieter, die in den Geltungsbereich der Verordnung fallen, schreibt der Anhang vor, dass sie Schwachstellen überwachen, gegebenenfalls in geplanten Abständen dokumentierte Scans durchführen und betriebskritische Schwachstellen unverzüglich beheben müssen. Sicherheitspatches müssen innerhalb einer angemessenen Frist installiert, vor dem Einsatz in der Produktion getestet, aus vertrauenswürdigen Quellen bezogen und auf ihre Integrität überprüft werden. Wenn eine Schwachstelle bewusst nicht behoben wird, sollte die Begründung dokumentiert werden. Zudem empfiehlt sich eine enge Abstimmung mit Change-, Risiko- und Incident-Management. Anhang, Punkte 6.6 und 6.10
Deutschland und das BSI-Gesetz
Das deutsche NIS2-Umsetzungsgesetz trat am 6. Dezember 2025 in Kraft. Das BSI-Gesetz (BSIG) verwendet die Kategorien „besonders wichtige Einrichtungen“ und „wichtige Einrichtungen“. Unternehmen sollten vor der Anwendung dieser Checkliste prüfen, ob sie in den Anwendungsbereich fallen. Ankündigung zur Einführung von BSI
- 30 Abs. 2 Nr. 5 BSIG bezieht ausdrücklich das Schwachstellenmanagement und die Offenlegung von Schwachstellen ein. § 30 Abs. 1 schreibt die Dokumentation der Erfüllung der Risikomanagementpflicht vor. § 30 Abs. 3 räumt dem EU-Durchführungsrechtsakt für die aufgeführten Anbietertypen Vorrang ein. § 30 BSIG
- 38 BSIG befasst sich mit der Umsetzung durch die Geschäftsleitung, der Aufsicht, der Haftung und regelmäßigen Schulungen. § 32 legt die Meldepflichten bei schwerwiegenden Vorfällen fest. Diese deutschen Bestimmungen sind im Zusammenhang mit den für die Unternehmen geltenden EU-Vorschriften zu betrachten. §38 BSIG §32 BSIG
Gesetzliche Anforderungen und praktische Hinweise. In den nationalen Durchführungsvorschriften und den geltenden EU-Verordnungen sind organisatorische Verpflichtungen festgelegt. Die NIS2-Richtlinie legt den EU-Rechtsrahmen fest; Leitlinien der ENISA und der Regulierungsbehörden dienen als Hilfestellung bei der Auslegung. Der nachstehend aufgeführte Arbeitsablauf, das Reifegradmodell, die vorgeschlagenen Verantwortlichen und die Beispielformate für Nachweise dienen als operative Leitlinien. Für Unternehmen, die in den Anwendungsbereich fallen, können zudem gesetzlich vorgeschriebene spezifische Kontrollmaßnahmen erforderlich sein.
Schwachstellenanalyse versus Schwachstellenmanagement
| Schwachstellenanalyse | Schwachstellenmanagement | |
| Eigenschaft | Erkennt und bewertet Schwachstellen; kann wiederholt oder automatisiert werden | Kontinuierlicher Lifecycle der Risikobehandlung und -überwachung |
| Ergebnisse | Feststellungen, Analyse und Empfehlungen | Priorisierte Maßnahmen, überprüfte Ergebnisse und nachverfolgte Restrisiken |
| Eigentümerschaft | Festgelegter Bewertungsumfang und Zuständigkeit | Verantwortlichkeit bei Bewertung, Umsetzung und Überprüfung |
| Nachweise | Bewertungsmethoden, Umfang und Ergebnisse | Aufzeichnungen über den gesamten Lifecycle hinweg |
Schwachstellenmanagement im Vergleich zu Patch-Management und Penetrationstests
| Vorgehensweise | Rolle | Typische Nachweise |
| Patch-Management | Eine Fehlerbehebungsmaßnahme: Installation von Hersteller-Updates | Patch-Status und Bereitstellungsaufzeichnungen |
| Penetrationstests | Prüft, ob Schwachstellen ausgenutzt werden können | Prüfbericht und Ergebnisse der Nachprüfung |
| Abgestimmte Offenlegung | Koordiniert die Berichterstattung, die Fehlerbehebungsmaßnahmen und die Offenlegung gegenüber den betroffenen Parteien | Offenlegungsverfahren und Koordinierungsunterlagen |
Patching ist eine Methode zur Fehlerbehebung. Zu den Fehlerbehebungsmaßnahmen können auch Upgrades, die Deinstallation von Software oder Konfigurationsänderungen gehören, durch die eine Schwachstelle behoben wird. Isolierung und Ausgleichsmaßnahmen können Risiken mindern, ohne die Schwachstelle zu beseitigen. Die Risikoakzeptanz ist eine eigenständige Entscheidung: Eine genehmigte Ausnahme bedeutet nicht, dass die Schwachstelle behoben wurde.
Ein praxisorientierter Lifecycle für das Schwachstellenmanagement gemäß NIS2
Dieses achtstufige Modell dient als praktische Orientierungshilfe und stellt keine Vorschrift gemäß NIS2 dar.
- Umfang und Zuständigkeit festlegen. Ermitteln Sie die geltenden rechtlichen Verpflichtungen, die betroffenen Systeme und die relevanten Lieferanten und benennen Sie die Verantwortlichen.
- Assets und Software inventarisieren. Berücksichtigen Sie relevante Server, Endpunkte, Netzwerkgeräte, Cloud-Dienste und gegebenenfalls auch die Betriebstechnik.
- Schwachstellen aufdecken. Verwenden Sie geeignete Scan- oder Bewertungsmethoden, Herstellerhinweise und andere Informationsquellen.
- Ergebnisse überprüfen und in einen Kontext einordnen. Falsche positive Ergebnisse entfernen und Asset-Kontext hinzufügen.
- Geschäftsrisiken nach Priorität sortieren. Siehe unten.
- Beheben oder mindern. Patchen Sie, nehmen Sie Neukonfigurationen vor, entfernen Sie anfällige Software, isolieren Sie Systeme oder wenden Sie gegebenenfalls Ausgleichsmaßnahmen an.
- Ergebnisse überprüfen. Stellen Sie sicher, dass die Korrekturen funktioniert haben und die Abhilfemaßnahmen wirksam sind; halten Sie akzeptierte oder geminderte Schwachstellen so lange sichtbar, bis sie behoben sind.
- Nachweise sichern und verbessern. Überprüfen Sie die Kennzahlen und optimieren Sie den Prozess.
Nach Risiko und nicht nur nach Schweregrad priorisieren
Verwenden Sie CVE-Kennungen zur Erfassung von Schwachstellen und CVSS-Werte als einen der Faktoren bei der Priorisierung. Zu berücksichtigen sind außerdem bekannte Ausnutzung, Exposition, Wichtigkeit der Assets, Geschäftsauswirkungen, verfügbare Behebungsmaßnahmen und betriebliche Einschränkungen. Die Richtlinie legt weder eine einheitliche Scan-Häufigkeit noch eine feste Frist für die Behebung fest, die für jede Schwachstelle und jede betroffene Stelle gilt. Legen Sie risikobasierte Ziele fest, die den geltenden nationalen und EU-Anforderungen entsprechen; interne Richtlinien dürfen diese nicht außer Kraft setzen. Artikel 21
Zu den nützlichen Informationen für die Priorisierung gehören:
- Ausnutzbarkeit: ob eine Ausnutzung bekannt ist oder wahrscheinlich ist
- Exposition: aus dem Internet erreichbar, intern oder isoliert
- Asset-Bedeutung: der Geschäftsprozess oder die Daten, die das System unterstützt
- Verfügbarkeit der Fehlerbehebun: ein Anbieter-Patch, eine Umgehungslösung oder nichts von beidem
- Operatives Risiko: das Risiko, das mit der Änderung selbst verbunden ist, wie Ausfallzeiten
Ausnahme- und Eskalationspfade festlegen
Wenn eine Schwachstelle nicht sofort behoben werden kann, halten Sie den Grund, die Ausgleichsmaßnahmen, das Restrisiko, den Verantwortlichen, den Genehmigungsbefugten und das Überprüfungsdatum fest. Wesentliche Risiken an die Geschäftsleitung eskalieren. Die Risikoakzeptanz bedeutet weder einen Verzicht auf eine gesetzliche Verpflichtung noch die Beseitigung der zugrunde liegenden Schwachstelle. Für Unternehmen, die unter die Verordnung 2024/2690 fallen, muss die Entscheidung, einen verfügbaren Sicherheitspatch nicht zu installieren, durch Nachteile begründet werden, die die Vorteile für die Cybersicherheit überwiegen; darüber hinaus sind zusätzliche Maßnahmen und die Akzeptanz von Restrisiken erforderlich. Anhang, Punkt 6.6
Zuordnung von Anforderungen zu Workflows
| NIS2-Thema | Operative Tätigkeit | Vermutlicher Eigentümer | Beispiel für Nachweise |
| Umgang mit Schwachstellen (Art. 21 Abs. 2 Buchstabe e; Verordnung 2024/2690, Anhang Punkt 6.10) | Erkennen, priorisieren, beheben, überprüfen | IT-Operations und -Sicherheit | Scan-Ergebnisse, Tickets, Patch-Protokolle |
| Abgestimmte Offenlegung (Art. 12 und Art. 21 Abs. 2 Buchstabe e) | Meldungen entgegennehmen oder veranlassen und Fehlerbehebungsmaßnahmen sowie die Offenlegung koordinieren | Sicherheit | Offenlegungsverfahren und Koordinierungsprotokoll |
| Vorfallbearbeitung | Verringere die Anzahl der ausgenutzten Schwachstellen im Vorfall-Workflow | Sicherheit | Eskalations- und Vorfallprotokolle |
| Lieferkettensicherheit | Schwachstellen bei Lieferanten und Produkten bewerten | Beschaffung und Sicherheit | Lieferantenbewertungen |
| Aufsicht durch die Geschäftsleitung (Art. 20) | Maßnahmen genehmigen und überwachen; Managementschulungen durchführen | Führung und Compliance | Beschlüsse, Protokolle von Überprüfungssitzungen und Schulungsunterlagen |
| Sicherheits-Patch-Management (Verordnung 2024/2690, Anhang Punkt 6.6) | Patches testen, bereitstellen und überprüfen; Ausnahmen begründen | IT-Operations und -Sicherheit | Test-, Bereitstellungs- und Ausnahmesätze |
Diese Zuordnung verknüpft rechtliche Themen mit operativen Tätigkeiten und Beispieldatensätzen. Die vorgeschlagenen Eigentümer und Nachweisformate können angepasst werden; die geltenden gesetzlichen Anforderungen bleiben verbindlich.
Reifeverlauf
| Phase | Typische Merkmale | Qualität der Nachweise |
| Fragmentiert | Ad-hoc-Scans, unklare Zuständigkeiten, separate Tools | Unbeständig, schwer reproduzierbar |
| Periodisch | Geplante Scans und Patch-Zyklen | Veraltete Berichte, Lücken zwischen den Zyklen |
| Verwaltet | Festgelegte Verantwortliche, risikobasierte Prioritäten, Ausnahmeregister | Konsistente Aufzeichnungen pro Zyklus |
| Kontinuierlich und dokumentiert | Kontinuierliche Transparenz, nachgewiesene Ergebnisse, nachverfolgte Restrisiken und Berichterstattung an die Führungsspitze | Aktuell, exportierbar, geprüft |
Zusammenhang zwischen Schwachstellen, Vorfällen und Anbietern
Eine ausgenutzte Schwachstelle kann zu einem Sicherheitsvorfall führen. Legen Sie fest, wie Erkenntnisse in die Vorfallbearbeitung einfließen und wie die Teams beurteilen, ob ein Vorfall die geltenden Meldekriterien erfüllt. Halten Sie die Fristen für die Schwachstellenbehebung getrennt von den Fristen für die Meldung schwerwiegender Vorfälle. Artikel 23 legt den Rahmen für die Berichterstattung in der EU fest; die deutschen Pflichten sind in § 32 BSIG geregelt. Artikel 23
Gemäß § 32 BSIG müssen betroffene deutsche Unternehmen schwerwiegende Vorfälle unverzüglich melden, wobei eine Frühwarnung spätestens 24 Stunden und eine Vorfallmeldung spätestens 72 Stunden nach Bekanntwerden erfolgen muss. Ein Abschlussbericht ist in der Regel innerhalb eines Monats nach Meldung des Vorfalls fällig; sollte der Vorfall noch andauern, wird er zu diesem Zeitpunkt durch einen Zwischenbericht ersetzt. Hierbei handelt es sich um Fristen für die Meldung von Vorfällen, nicht um Fristen für die Installation von Patches. §32 BSIG
Zweitens bringen Lieferanten und Produkte Schwachstellen mit sich, auf die Sie keinen Einfluss haben. NIS2 betrachtet die Sicherheit der Lieferkette als Teil derselben Maßnahmen gemäß Artikel 21. Erfassen Sie daher, welche Anbieter und Produkte am wichtigsten sind, erkundigen Sie sich, wie diese mit Schwachstellen umgehen und diese offenlegen, und verfolgen Sie deren Sicherheitshinweise parallel zu Ihren eigenen Erkenntnissen.
Auch die koordinierte Offenlegung von Schwachstellen erfordert einen festgelegten Prozess: Entgegennahme oder Einreichung von Meldungen, Ermittlung der betroffenen Anbieter und Dienste, Vereinbarung von Fehlerbehebungsmaßnahmen und des Zeitpunkts der Offenlegung sowie Einbeziehung des zuständigen CSIRT, wenn Unterstützung benötigt wird. Die betroffenen Anbieter müssen ihr Verfahren zur Offenlegung von Schwachstellen an die geltenden nationalen Richtlinien zur koordinierten Offenlegung von Schwachstellen anpassen. Artikel 12 Anhang, Punkt 6.10
Wie sich die Aufsicht durch die Geschäftsleitung auf das Programm auswirkt
Artikel 20 schreibt die Genehmigung und Überwachung von Maßnahmen zum Management von Cybersicherheitsrisiken durch die Geschäftsleitung vor, wie sie in nationales Recht umgesetzt wurden, sowie Schulungen für die Mitglieder der Leitungsgremien. In Deutschland verpflichtet § 38 BSIG die Geschäftsleitung dazu, die Maßnahmen umzusetzen und zu überwachen sowie an regelmäßigen Schulungen teilzunehmen, wobei die Haftung den geltenden Vorschriften unterliegt. Das Schwachstellenmanagement erfordert daher die Einbindung der Führungskräfte und eine entsprechende Berichterstattung. Zu den sinnvollen Maßnahmen gehören: §38 BSIG
- Abdeckung: Anteil der erfassten Endpunkte und Systeme, die im Bestand sichtbar sind
- Exposition: Offene Schwachstellen mit hoher Priorität und seit wann sie offen sind
- Ausnahmen: Anzahl der akzeptierten Anträge und Anzahl der Anträge, deren Prüfungsfrist bereits abgelaufen ist
- Überprüfung: Anteil der als abgeschlossen bestätigten Fehlerbehebungsmaßnahmen, wobei geminderte und akzeptierte Risiken separat erfasst werden
Wählen Sie Maßnahmen, die zu Ihrer Risikostrategie passen. Erfassen Sie Entscheidungen der Führungskräfte und Schulungen und leiten Sie überfällige Maßnahmen oder Änderungen des Risikos weiter.
Häufige Schwachstellen, die ein Programm beeinträchtigen
- Ein Inventar, bei der nicht verwaltete Geräte oder Software von Drittanbietern nicht erfasst werden
- Priorisierung ausschließlich auf der Grundlage von Schweregraden
- Das Patching wurde nachverfolgt, es gibt jedoch keine Bestätigung, dass die Korrekturen wirksam wurden
- Ausnahmen, die in E-Mails statt in einem Register erfasst werden
- Es gibt kein Verfahren für die Entgegennahme von Schwachstellenmeldungen oder die Abstimmung der Offenlegung mit den betroffenen Anbietern und anderen Beteiligten.
- Berichte ohne Datum, Eigentümer oder Quellsystem
Welche Unterlagen sollten Unternehmen aufbewahren?
- Asset- und Software-Inventare
- Bewertungs- und Scan-Ergebnisse, einschließlich Umfang, Zeiträume und Quellsysteme
- Behebungsaufträge, Aufzeichnungen zu Patch-Tests und zur Bereitstellung sowie Aufzeichnungen zu Abhilfemaßnahmen
- Begründete Ausnahmeentscheidungen, Restrisiken, kompensierende Kontrollmaßnahmen, Verantwortliche und Überprüfungstermine
- Überprüfungsergebnisse zur Unterscheidung zwischen behobenen Schwachstellen und geminderten oder akzeptierten Risiken
- Offenlegungsverfahren und Aufbewahrung von Unterlagen
- Aufzeichnungen zur Lieferantenbewertung
- Kennzahlen, Aufzeichnungen zu Führungskräftebeurteilungen und Aufzeichnungen zu Managementschulungen
Wie die Unternehmensleitung, die IT-Sicherheit und die MSPs die Verantwortung gemeinsam tragen
Sicherheit identifiziert Risiken und ordnet sie in einen Kontext ein. Der IT-Betrieb führt Änderungen durch und überprüft sie. Compliance hilft dabei, Nachweise zu ordnen. Die Unternehmensleitung genehmigt das Vorgehen, überwacht die Umsetzung, überprüft die Leistung und trifft im Rahmen der geltenden gesetzlichen Vorschriften autorisierte Risikobeschlüsse. Die Berichterstattung sollte offene Risiken, überfällige Maßnahmen und Ausnahmen deutlich machen.
MSPs können Richtlinien, Tools und Formate für Nachweise kundenübergreifend vereinheitlichen. Jeder betroffene Kunde trägt weiterhin die Verantwortung für seine eigenen Verpflichtungen und Risikobewertungen. Ein MSP kann zudem eigene NIS2-Verpflichtungen haben, einschließlich derjenigen gemäß der Verordnung 2024/2690, sofern er in deren Anwendungsbereich fällt; diese sind unabhängig von den Dienstleistungen, die er für seine Kunden erbringt. Geltungsbereich der Verordnung
Wo Endpunktmanagement und Patch-Automatisierung helfen können
NinjaOne vereint Endpunktmanagement, Schwachstellenmanagement und autonomes Patch-Management in einer einheitlichen IT-Betriebsplattform. Für interne IT-Teams und MSPs können diese Funktionen die Transparenz, Priorisierung, Fehlerbehebung und das operative Reporting über alle verwalteten Endpunkte hinweg unterstützen. Endpunkt-Tools unterstützen einen Teil des übergeordneten Programms; Unternehmen müssen sich jedoch auch mit anderen relevanten Systemen, Diensten und Lieferanten befassen. NinjaOne Vulnerability Management
Technologie unterstützt Sicherheitsmaßnahmen und die Beweissicherung. Schwachstellenmanagement allein macht ein Unternehmen noch nicht NIS2-konform. Es ersetzt auch nicht die Governance, die geltenden gesetzlichen Pflichten oder weitere notwendige Sicherheitsmaßnahmen, etwa zur Erkennung von und Reaktion auf Bedrohungen.
Checkliste zum Schwachstellenmanagement gemäß NIS2
- Den Geltungsbereich gemäß den nationalen Durchführungsvorschriften bestätigen und prüfen, ob die Verordnung 2024/2690 Anwendung findet
- Verantwortliche Ansprechpartner in den Bereichen Führung, Sicherheit, IT, Compliance und Anbieter bestimmen
- Ein genaues Inventar der Systeme, der Software und der Endpunkte führen
- Festlegen, wie Schwachstellen aufgedeckt, überprüft, klassifiziert, priorisiert und zugewiesen werden, einschließlich dokumentierter Überprüfungsintervalle und Reaktionsziele
- Risikobasierte Kriterien und nicht allein Schweregrade verwenden
- Workflows für Patch-Tests, Bereitstellung, Abhilfemaßnahmen, Überprüfung, Ausnahmen und Eskalationen dokumentieren
- Verfahren zum Umgang mit Schwachstellen und zur koordinierten Offenlegung festlegen
- Ergebnisse mit der Bearbeitung und Meldung von Vorfällen verknüpfen
- Schwachstellenrisiken bei Anbietern und in der Lieferkette analysieren
- Bewertungsergebnissen, Aufzeichnungen über Abhilfemaßnahmen, begründeten Ausnahmen, Managemententscheidungen und Schulungsunterlagen aufbewahren
- Die Wirksamkeit des Programms überprüfen, die Kennzahlen mit der Führungsebene besprechen und die Schulungen für Führungskräfte aufrechterhalten
- Bei qualifizierten Beratern über die länderspezifischen Anforderungen informieren
