Geschäftsleitungspflichten

Die NIS2-Umsetzung in Deutschland legt erstmals persönliche Pflichten der Geschäftsleitung für Cybersicherheit fest:

Governance-Struktur

Berichtswesen

Schulungspflicht der Geschäftsleitung

Die Geschäftsleitung nimmt mindestens jährlich an einer Cybersicherheitsschulung teil, die folgende Inhalte abdeckt:

• Aktuelle Bedrohungslage und relevante Vorfälle
• NIS2/BSIG-Pflichten und Haftung
• Risikomanagement und Maßnahmenbewertung
• Incident-Response-Prozess und Eskalation

Schulungsprogramm

Basisschulung (alle Mitarbeiter)

Rollenspezifische Schulung

Onboarding

Neue Mitarbeiter erhalten vor Zugriff auf Systeme:

• Einweisung in Informationssicherheitspolitik
• Basisschulung Cyberhygiene
• Bestätigung der Sicherheitsrichtlinien

Dokumentation

• Teilnahmenachweise werden zentral geführt
• Schulungsabschluss ist Voraussetzung für System-Zugriffsrechte
• Jährliche Auswertung der Abschlussquoten als KPI

Multi-Faktor-Authentifizierung

MFA-Pflicht

MFA-Methoden (Rangfolge)

MFA-Ausnahmen

Ausnahmen von der MFA-Pflicht sind nur in begründeten Fällen möglich:

• Dokumentierte Begründung erforderlich
• ISB-Freigabe zwingend
• Kompensierende Maßnahmen definiert
• Befristet mit Wiedervorlage
• Service-Accounts: IP-Whitelisting + API-Key statt MFA

Passwort-Richtlinie

Service-Accounts

Zugriffskontrollmodell

Die BAUER GROUP setzt ein rollenbasiertes Zugriffskontrollmodell (RBAC) ein:

Rollenmodell

Berechtigungsprozess

Vergabe

1. Antragstellung durch Mitarbeiter oder Vorgesetzten
2. Genehmigung durch zuständigen Daten-/Systemverantwortlichen
3. Umsetzung durch IT
4. Dokumentation im Berechtigungsinventar

Änderung

1. Bei Rollenwechsel: Alte Berechtigungen entziehen, neue vergeben
2. Frist: Innerhalb von 5 Arbeitstagen nach Rollenwechsel
3. Review alter Berechtigungen durch Vorgesetzten

Entzug (Offboarding)

Berechtigungsaudit

Kommunikationskanäle

E-Mail-Sicherheit im Detail

DNS-basierte Authentifizierung

Handling vertraulicher Daten per E-Mail

Notfallkommunikation

Fallback-Kanäle

Für den Fall, dass primäre Kommunikationskanäle kompromittiert oder nicht verfügbar sind:

Vorbereitungsmaßnahmen

• Aktuelle Kontaktlisten der Schlüsselpersonen offline verfügbar (gedruckt oder auf separatem Gerät)
• Vordefinierte Codewörter für Echtheitsprüfung bei telefonischer Kommunikation
• Jährliche Erreichbarkeitsübung mit allen Krisenstabsmitgliedern
• Backup-Kommunikationsplan ist Teil der Krisenmanagement-Dokumentation

3-2-1-Regel im Detail

Backup-Typen

Backup-Ziele nach Datentyp

Restore-Verifikation

Monitoring

• Backup-Erfolg/-Fehlschlag wird automatisch überwacht
• Fehlgeschlagene Backups erzeugen sofortige Alerts
• Speicherkapazität und Aufbewahrungsfristen werden überwacht
• Monatlicher Backup-Report an ISB

Krisendefinition

Eine Krise liegt vor, wenn ein Sicherheitsvorfall:

• Die Handlungsfähigkeit der Organisation gefährdet
• Mehrere Systeme oder Standorte gleichzeitig betrifft
• Externe Kommunikation mit Kunden, Behörden oder Medien erfordert
• Die regulären Eskalationswege nicht ausreichen

Krisenstab

Krisenablauf

Phase 1: Alarmierung (< 1 Stunde)

• ISB alarmiert Krisenstab per Mobiltelefon (kein E-Mail wenn Systeme kompromittiert)
• Erstlagebild: Was ist bekannt, was ist betroffen, was ist die unmittelbare Bedrohung?
• Krisenstab-Meeting (physisch oder Telefonkonferenz über Backup-Kanal)

Phase 2: Lagebild (< 4 Stunden)

• Vollständige Betroffenheitsanalyse
• Entscheidung über Kommunikationsstrategie
• BSI-Meldung vorbereiten (falls meldepflichtiger Vorfall)
• Kundeninformation vorbereiten (falls betroffen)

Phase 3: Bewältigung (Tage bis Wochen)

• Koordinierte Wiederherstellung nach DR-Plan
• Regelmäßige Krisenstab-Updates (mindestens täglich)
• Laufende BSI-Kommunikation
• Kundenkommunikation (Statusupdates)

Phase 4: Rückkehr zum Normalbetrieb

• Verifizierung aller wiederhergestellten Systeme
• Aufhebung des Krisenmodus durch Geschäftsleitung
• Übergabe an Regelbetrieb

Phase 5: Nachbereitung (< 30 Tage)

• Umfassende Post-Mortem-Analyse
• BSI-Abschlussbericht
• Lessons Learned und Maßnahmenplan
• Anpassung von DR-Plan, Playbooks und Risikoanalyse

Krisenübungen

Wiederherstellungsziele

Wiederherstellungsprozeduren

Szenario: Einzelsystem-Ausfall

1. Ursache identifizieren (Hardware, Software, Konfiguration)
2. Failover aktivieren (falls vorhanden)
3. System aus Backup wiederherstellen oder neu aufsetzen
4. Konfiguration aus Git-Repository anwenden
5. Integritätsprüfung vor Wiederinbetriebnahme
6. Monitoring für 24h verstärken

Szenario: Ransomware

1. Sofort: Alle betroffenen Systeme vom Netz isolieren
2. Umfang der Verschlüsselung bestimmen
3. Backup-Integrität prüfen (saubere Backups identifizieren)
4. Systeme aus verifizierten Backups wiederherstellen
5. Alle Credentials rotieren
6. Angriffsvektor schließen bevor Systeme wieder online gehen

Szenario: Rechenzentrumsausfall

1. Krisenstab aktivieren
2. Failover auf Sekundärstandort (falls vorhanden)
3. Priorisierte Wiederherstellung nach Dienstkategorie
4. Kundenkommunikation aktivieren
5. Provisorischen Betrieb sicherstellen
6. Vollständige Wiederherstellung nach Verfügbarkeit des Primärstandorts

Failover-Systeme

DR-Tests

Detaillierte Anforderungszuordnung

§30 Nr. 2 – Vorfallmanagement ↔ CRA Art. 14

§30 Nr. 4 – Lieferkette ↔ CRA Annex I Teil II Nr. 1

§30 Nr. 5 – Schwachstellen ↔ CRA Art. 10/11

AI-Act-Synergien

Gesamtbild

NIS2 (Organisation & Betrieb)
  ├── Risikomanagement ←──── AI Act (KI-Risikomanagement, Art. 9)
  ├── Vorfallmanagement ←──── CRA (Produkt-Incidents, Art. 14)
  ├── Supply Chain ←──── CRA (Software-SBOM, Annex I)
  ├── Schwachstellen ←──── CRA (Produkt-CVEs, Art. 10/11)
  ├── Schulung ←──── AI Act (AI Literacy, Art. 4)
  └── Kryptografie ←──── AI Act (Cybersicherheit, Art. 15)
                    ←──── CRA (Produktverschlüsselung, Annex I)

Protokoll-Anforderungen

TLS (Transport Layer Security)

SSH

E-Mail (SMTP)

Datenbank-Verschlüsselung

Backup-Verschlüsselung

Schlüssel-Lebenszyklus

Rotationsintervalle

Zertifikatsverwaltung

Inventar

Alle Zertifikate werden zentral erfasst:

Monitoring

Widerrufsprozess

Bei Kompromittierung eines Zertifikats:

1. Sofortiger Widerruf bei der CA
2. Neues Zertifikat ausstellen und deployen
3. Prüfen ob der kompromittierte Schlüssel anderweitig eingesetzt wurde
4. Vorfall dokumentieren und in Risikoanalyse aufnehmen

Audit-Typen

Audit-Scope

Internes ISMS-Audit

Penetrationstest-Scope

Audit-Dokumentation

Jedes Audit wird dokumentiert mit:

• Audit-Scope und -Zeitraum
• Prüfmethodik
• Findings mit Schweregrad (Kritisch / Hoch / Mittel / Niedrig / Informational)
• Empfohlene Maßnahmen
• Verantwortlicher und Frist für Behebung
• Follow-up-Termin

Finding-Management

Sicherheits-KPIs

Schwachstellenmanagement

Incident Management

Zugriffskontrolle

Business Continuity

Schulung

Reporting

Gesetzliche Pflichten

§38 Abs. 1 – Billigung und Überwachung

Die Geschäftsleitung ist persönlich verpflichtet:

§38 Abs. 2 – Persönliche Haftung

• Geschäftsleitungen haften für Schäden, die durch Verletzung ihrer Pflichten aus Absatz 1 entstehen
• Verzichtsvereinbarungen sind unwirksam
• Vergleiche über Ersatzansprüche sind unwirksam
• Schadensersatzansprüche der Einrichtung gegen die Geschäftsleitung können nicht ausgeschlossen werden

§38 Abs. 3 – Schulungspflicht

• Geschäftsleitungen müssen regelmäßig an Schulungen teilnehmen
• Zweck: Ausreichende Kenntnisse zur Erkennung und Bewertung von Risiken
• Inhalt: Risikomanagementpraktiken und deren Auswirkung auf die Dienste der Einrichtung

Umsetzung bei BAUER GROUP

Billigungsprozess

Überwachungsmechanismen

Schulungsnachweis

Haftungsminimierung

Zur Minimierung des persönlichen Haftungsrisikos der Geschäftsleitung empfiehlt sich:

Organisationsstruktur

Geschäftsleitung
  ├── Informationssicherheitsbeauftragter (ISB)
  │     ├── Risikoanalyse & ISMS
  │     ├── Incident Management & BSI-Kontakt
  │     ├── Audit & Compliance
  │     └── Schulung & Awareness
  ├── IT-Leitung
  │     ├── IT-Operations (Server, Netzwerk, Cloud)
  │     ├── Softwareentwicklung
  │     └── Helpdesk / Support
  └── Datenschutzbeauftragter (DSB)
        └── DSGVO-Compliance

ISB – Rolle und Befugnisse

Reporting-Struktur

Regelmäßige Berichte

Anlassbezogene Berichte

Dokumentationspflichten

Folgende Dokumente werden gepflegt und sind jederzeit verfügbar:

Eskalationsmatrix

Kommunikationsplan

Interne Kommunikation

Externe Kommunikation

Kundeninformation bei Vorfällen

Wenn ein Sicherheitsvorfall Kundendaten oder -dienste betrifft, umfasst die Benachrichtigung:

• Art und Umfang des Vorfalls
• Betroffene Daten oder Dienste
• Ergriffene Gegenmaßnahmen
• Empfohlene Maßnahmen für den Kunden
• Ansprechpartner für Rückfragen
• Voraussichtliche Dauer der Einschränkung

Notfallkontakte

Folgende Kontakte sind jederzeit erreichbar (auch außerhalb der Geschäftszeiten):

Dreistufiges Meldemodell

Stufe 1: Frühwarnung (24 Stunden)

Stufe 2: Aktualisierung (72 Stunden)

Stufe 3: Abschlussbericht (1 Monat)

Kriterien für erhebliche Sicherheitsvorfälle

Ein Vorfall ist erheblich, wenn mindestens eines der folgenden Kriterien erfüllt ist:

Meldeprozess intern

Vorfall erkannt
  → ISB informiert (< 1h)
    → Erstbewertung: Erheblich ja/nein? (< 4h)
      → Wenn ja: BSI-Frühwarnung vorbereiten (< 24h)
        → Geschäftsleitung informieren
          → DSGVO-Meldung prüfen (Art. 33: 72h an Aufsichtsbehörde)
            → CRA-Meldung prüfen (Art. 14: 24h an ENISA)

Parallele Meldepflichten

Dokumentation

Jeder meldepflichtige Vorfall wird vollständig dokumentiert:

• Chronologischer Ablauf mit Zeitstempeln
• Alle Entscheidungen mit Begründung
• Kommunikation mit BSI (Melde-IDs, Korrespondenz)
• Maßnahmen und deren Wirksamkeit
• Lessons Learned und Folgemaßnahmen

Aufbewahrungsfrist: Mindestens 3 Jahre nach Abschluss des Vorfalls.

5-Phasen-Modell

Der Incident-Response-Prozess der BAUER GROUP folgt dem etablierten NIST SP 800-61-Framework, angepasst an die Anforderungen des §30 Abs. 2 Nr. 2 BSIG.

Phase 1: Vorbereitung

Phase 2: Erkennung und Analyse

Analyseschritte:

1. Erstbewertung: Ist der Vorfall real? (Triage)
2. Klassifikation nach Schweregrad (Kritisch / Hoch / Mittel / Niedrig)
3. Betroffenheitsanalyse: Welche Systeme, Daten, Kunden sind betroffen?
4. Meldepflichtprüfung: Liegt ein erheblicher Vorfall nach §32 BSIG vor?
5. Forensische Erstbewertung: Angriffsvektor, Zeitraum, Indikatoren (IoC)

Phase 3: Eindämmung

Phase 4: Beseitigung und Wiederherstellung

Phase 5: Nachbereitung

Playbooks

Für die häufigsten Szenarien bestehen vordefinierte Response-Playbooks:

Grundprinzip

Die BAUER GROUP unterliegt drei komplementären EU-Regulierungen zur Cybersicherheit. Um Doppelarbeit zu vermeiden und den internen Compliance-Aufwand zu minimieren, werden Synergien systematisch genutzt: Bestehende Prozesse aus der CRA- und AI-Act-Compliance werden für NIS2 referenziert, nicht dupliziert.

Synergieübersicht

Detaillierte Synergien

Schwachstellenmanagement (Nr. 5)

Meldepflichten (Nr. 2 / §32)

Lieferkette (Nr. 4)

Aufwandsoptimierung

Durch konsequente Nutzung der CRA-Basisarbeit reduziert sich der NIS2-spezifische Mehraufwand auf:

Zweck

Das Asset-Inventar erfasst alle informationstechnischen Systeme, Komponenten und Prozesse der BAUER GROUP. Es bildet die Grundlage für die Risikoanalyse und ermöglicht die Zuordnung von Schutzmaßnahmen zu konkreten Assets.

Asset-Kategorien

Serversysteme

Netzwerkkomponenten

• Firewalls mit Regelwerk-Version und letztem Review-Datum
• Switches und Router mit Firmware-Version
• VPN-Gateways und Zugangspunkte
• DNS-Server und Load Balancer

Anwendungen

Cloud-Dienste

• Anbieter mit Standort und Rechtsraum
• Vertragslaufzeit und SLAs
• Datenklassifizierung der gespeicherten Daten
• Exit-Strategie und Datenportabilität

Datenbestände

Pflege

Zweck

Die Informationssicherheitspolitik definiert den Rahmen für den Schutz aller informationstechnischen Systeme, Komponenten und Prozesse der BAUER GROUP. Sie ist die oberste Leitlinie des ISMS und wird durch die Geschäftsleitung freigegeben.

Schutzziele

Geltungsbereich

Die Informationssicherheitspolitik gilt für:

• Alle Mitarbeiter, Geschäftsleitung und externe Dienstleister mit Systemzugriff
• Alle informationstechnischen Systeme im Eigenbetrieb und bei Drittanbietern
• Alle Standorte und Remote-Arbeitsplätze
• Alle Phasen des Informationslebenszyklus (Erstellung, Verarbeitung, Speicherung, Löschung)

Verantwortlichkeiten

Überprüfungszyklus

Klassifizierungsschema

Methodik

Die Risikoanalyse folgt einem strukturierten Prozess, orientiert an ISO 27005 und BSI IT-Grundschutz:

Kontext festlegen → Risiken identifizieren → Risiken analysieren → Risiken bewerten → Risiken behandeln

Bedrohungskatalog

Risikobewertungsmatrix

Risiken werden nach Eintrittswahrscheinlichkeit und Auswirkung bewertet:

Risikobehandlungsplan

Für jedes identifizierte Risiko wird dokumentiert:

Prozessintegration

Pflichtklauseln

Verträge mit Dienstleistern, die Zugriff auf Systeme oder Daten der BAUER GROUP haben, enthalten folgende Mindestanforderungen:

Informationssicherheit

Vorfallmanagement

Prüf- und Auditrechte

Datenhandling

Exit-Strategie

Vertragsmanagement

Bewertungsprozess

Erstbewertung (vor Beauftragung)

Bewertungskriterien (Scoring)

Mindestpunktzahl: 12/18 für Standarddienstleister, 15/18 für kritische Dienstleister.

Wiederbewertung

Kategorisierung

Awareness-Programm

Laufende Maßnahmen

Phishing-Simulation

Cyberhygiene-Regeln

Arbeitsplatz

Passwörter & Authentifizierung

Kommunikation

Dokumentation

Pflichtschulungen

Basisschulung – Alle Mitarbeiter

Gesamtdauer: ~2 Stunden pro Jahr

Geschäftsleitungsschulung (§38 Abs. 3 BSIG)

Dauer: 2–3 Stunden pro Jahr, durch ISB oder externen Trainer

Rollenspezifische Schulungen

Schulungsmethoden

Patch-Fristen

Patch-Prozess

Standardprozess (Mittel/Niedrig)

1. Schwachstelle wird durch Scanning oder CVE-Monitoring identifiziert
2. Bewertung und Priorisierung
3. Patch in Staging-Umgebung testen
4. Deployment in Produktion innerhalb der Frist
5. Verifikation: Scan bestätigt Behebung

Notfall-Prozess (Kritisch/Hoch)

1. Sofortige Bewertung durch IT-Ops + ISB
2. Workaround implementieren falls Patch nicht sofort verfügbar (z.B. WAF-Regel, Netzwerkisolierung)
3. Patch testen (verkürzte Testphase, ggf. parallel)
4. Notfall-Deployment (außerhalb regulärer Wartungsfenster erlaubt)
5. Verifikation und Dokumentation

Ausnahmen

Wenn ein Patch innerhalb der Frist nicht möglich ist:

Patch-Tracking

Scanning-Programm

Infrastruktur-Scanning

Anwendungs-Scanning

CVE-Monitoring

Quellen

Bewertungsprozess

CVE veröffentlicht
  → Relevanzprüfung: Ist das betroffene Produkt bei uns im Einsatz?
    → Ja: CVSS-Bewertung + Kontextbewertung
      → Kritisch/Hoch: Sofortige Eskalation an IT-Ops
      → Mittel: Aufnahme in Patch-Zyklus
      → Niedrig: Nächster Release-Zyklus
    → Nein: Archivieren

Schwachstellen-Tracking

Jede identifizierte Schwachstelle wird dokumentiert:

Security im SDLC

CI/CD-Security-Pipeline

Jeder Commit durchläuft automatisiert:

Dependency Management

Secrets Management

Zugriffskontrollprinzipien

Authentifizierung

Multi-Faktor-Authentifizierung (MFA)

MFA ist verpflichtend für:

• Alle externen Zugriffe (VPN, Web-Portale)
• Administrative Systemzugriffe
• Cloud-Dienste und SaaS-Anwendungen
• E-Mail-Zugang

Bevorzugte MFA-Methoden: Hardware-Token (FIDO2/WebAuthn), Authenticator-App (TOTP). SMS-basierte MFA ist nicht zulässig.

Serverzugriff

• SSH mit Key-basierter Authentifizierung (Ed25519)
• Passwort-basierter SSH-Login deaktiviert
• Root-Login deaktiviert, Zugriff nur über personalisierte Accounts

Passwort-Management

On-/Offboarding

Sichere Kommunikation

Kommunikationskanäle

E-Mail-Sicherheit

• SPF – Sender Policy Framework für alle Domains konfiguriert
• DKIM – DomainKeys Identified Mail für Signaturprüfung
• DMARC – Domain-based Message Authentication, Reporting and Conformance (Policy: reject)

Notfallkommunikation

Für den Fall, dass primäre Kommunikationskanäle kompromittiert oder nicht verfügbar sind:

• Vordefinierte Fallback-Kommunikationswege (Telefon, alternativer Messenger)
• Aktuelle Kontaktlisten der Schlüsselpersonen offline verfügbar
• Regelmäßige Überprüfung der Erreichbarkeit

Backup-Strategie

Die BAUER GROUP wendet die 3-2-1-Regel an:

Backup-Intervalle

Wiederherstellungsziele

Disaster Recovery

• Regelmäßige Restore-Tests – Vierteljährliche Prüfung der Wiederherstellbarkeit
• Dokumentierte Wiederherstellungsprozeduren pro System
• Failover-Systeme für geschäftskritische Dienste
• Eskalationsplan mit klaren Verantwortlichkeiten und Kommunikationswegen

Krisenmanagement

Bei Eintritt eines Krisenfalls (z.B. Ransomware, Totalausfall):

1. Krisenstab aktivieren (ISB, Geschäftsleitung, IT-Leitung)
2. Lagebild erstellen und dokumentieren
3. Kommunikationsplan aktivieren (intern, Kunden, Behörden)
4. Wiederherstellung nach dokumentiertem DR-Plan
5. Nachbereitung mit Lessons Learned und Plananpassung

Vollständige Zuordnung aller NIS2-Anforderungen zu Dokumentation, Umsetzung und Synergien.

§30 BSIG – Risikomanagementmaßnahmen

Weitere BSIG-Pflichten

CRA-Synergien

AI-Act-Synergien

Standards

Die BAUER GROUP orientiert sich an den Empfehlungen des BSI (TR-02102) und ISO/IEC 27001 Annex A.10:

Verschlüsselung

Data at Rest

• Festplattenverschlüsselung auf allen Serversystemen
• Datenbank-Verschlüsselung für sensible Datenbestände
• Backup-Verschlüsselung (AES-256)

Data in Transit

• TLS 1.2+ für alle externen Verbindungen, TLS 1.3 bevorzugt
• SSH für Serveradministration (Ed25519-Schlüssel)
• VPN für Remote-Zugriff auf interne Systeme

Key Management

Zertifikatsmanagement

• Let's Encrypt für öffentliche TLS-Zertifikate (automatisierte Erneuerung)
• Monitoring der Zertifikatslaufzeiten
• Dokumentierte Prozesse für Zertifikatserneuerung und -widerruf

Jährliche Sicherheitsüberprüfung

Die Wirksamkeit der Risikomanagementmaßnahmen wird mindestens jährlich überprüft:

KPIs

Penetrationstests

• Externe Tests – Jährlich durch unabhängigen Dienstleister
• Interne Tests – Anlassbezogen bei wesentlichen Änderungen
• Scope – Infrastruktur, Webanwendungen, interne Systeme
• Ergebnisverwertung – Findings fließen in Risikoanalyse und Maßnahmenplanung ein

PDCA-Zyklus

Die kontinuierliche Verbesserung folgt dem Plan-Do-Check-Act-Zyklus:

Klassifikation

Incident-Response-Prozess

1. Erkennung und Meldung

• Monitoring-Systeme, Log-Analyse und manuelle Erkennung
• Jeder Mitarbeiter ist verpflichtet, Verdachtsfälle unverzüglich zu melden
• Zentrale Meldung an den Informationssicherheitsbeauftragten (ISB)

2. Analyse und Bewertung

• Einordnung nach Schweregrad (siehe Klassifikation)
• Bestimmung betroffener Systeme, Daten und Kunden
• Prüfung: Handelt es sich um einen meldepflichtigen Vorfall nach §32 BSIG?

3. Eindämmung

• Sofortisolierung kompromittierter Systeme
• Sperrung betroffener Zugangsdaten
• Aktivierung von Failover-Systemen bei Dienstausfall
• Beweissicherung vor Bereinigung

4. Beseitigung und Wiederherstellung

• Entfernung der Angriffsursache (Malware, kompromittierte Accounts)
• Wiederherstellung aus Backups bei Datenverlust
• Verifizierung der Systemintegrität vor Wiederinbetriebnahme
• Rotation aller potenziell kompromittierten Zugangsdaten

5. Nachbereitung

• Post-Mortem-Analyse mit Ursachenbestimmung (Root Cause Analysis)
• Dokumentation und Ableitung konkreter Verbesserungsmaßnahmen
• Aktualisierung der Risikoanalyse bei Bedarf

Eskalationsmatrix

Meldepflichten nach §32 BSIG

Erhebliche Sicherheitsvorfälle sind dem BSI nach einem dreistufigen Modell zu melden:

Kriterien für erhebliche Vorfälle

Ein Vorfall gilt als erheblich, wenn er:

• Schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste verursacht oder verursachen kann
• Andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt oder beeinträchtigen kann

Meldewege

• Meldeportal: BSI-Meldeplattform (online)
• Intern: ISB → Geschäftsleitung → BSI-Meldung
• Parallel: Datenschutzmeldung nach Art. 33 DSGVO prüfen, falls personenbezogene Daten betroffen

Diese Dokumentation beschreibt die Umsetzung der NIS-2-Richtlinie (EU) 2022/2555 und des deutschen NIS2-Umsetzungsgesetzes (NIS2UmsuCG) bei der BAUER GROUP. Sie umfasst alle zehn Risikomanagementmaßnahmen nach §30 Abs. 2 BSIG sowie die Pflichten aus §32 (Meldepflichten), §33 (Registrierung) und §38 (Geschäftsleitungspflichten).

Geltungsbereich

Die Dokumentation deckt folgende Bereiche der BAUER GROUP ab:

Komplementäre Dokumentation

Die BAUER GROUP unterhält drei komplementäre Compliance-Dokumentationen:

Wo sich Anforderungen überschneiden, wird auf die jeweils andere Dokumentation verwiesen, um Redundanzen zu vermeiden. Die CRA-Dokumentation deckt produktbezogene Cybersicherheitsanforderungen ab, die NIS2-Dokumentation organisatorische und betriebliche Anforderungen.

Aufbau der Dokumentation

Rechtsquellen

Betroffenheit

Die NIS2-Richtlinie unterscheidet zwei Kategorien:

§30 BSIG – Zehn Risikomanagementmaßnahmen

Weitere Pflichten

Abgrenzung CRA / NIS2

Informationssicherheitspolitik

Die BAUER GROUP betreibt ein Informationssicherheits-Managementsystem (ISMS), das die Schutzziele Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität abdeckt. Die Informationssicherheitspolitik wird jährlich durch die Geschäftsleitung überprüft und freigegeben.

Systematische Risikoanalyse

Die Risikoanalyse erfolgt nach einem standardisierten Prozess:

Risikobehandlungsoptionen

Asset-Inventar

Alle informationstechnischen Systeme, Komponenten und Prozesse werden in einem zentralen Inventar erfasst:

• Serversysteme – Physische und virtuelle Server mit Standort, Zweck und Verantwortlichem
• Netzwerkkomponenten – Firewalls, Switches, Router mit Firmware-Versionen
• Anwendungen – Eigenentwicklungen und Drittanbieter-Software mit Lizenz- und Supportstatus
• Datenbestände – Klassifizierung nach Schutzbedarf (normal, hoch, sehr hoch)
• Cloud-Dienste – Externe Dienste mit Anbieter, Standort und Vertragsstatus

Normenorientierung

Die Umsetzung orientiert sich an:

• ISO/IEC 27001:2022 – Informationssicherheits-Managementsysteme
• BSI IT-Grundschutz – Methodischer Rahmen für Risikoanalyse
• Durchführungsverordnung (EU) 2024/2690 – Detaillierte technische Anforderungen zu NIS2

Dienstleisterübersicht

Alle externen Dienstleister und Anbieter werden kategorisiert:

Bewertungskriterien

Vor Beauftragung und bei jährlicher Überprüfung werden Dienstleister anhand folgender Kriterien bewertet:

Vertragliche Sicherheitsanforderungen

Verträge mit Dienstleistern enthalten:

• Mindestanforderungen an Informationssicherheit
• Pflicht zur unverzüglichen Meldung von Sicherheitsvorfällen
• Audit- und Prüfrechte
• Regelungen zu Datenhaltung und -löschung
• Exit-Strategie und Datenrückgabe

Überprüfungszyklus

Dependency Management

Für Software-Abhängigkeiten:

• Automatisiertes Dependency-Monitoring (Dependabot)
• Bewertung von Schwachstellen in Drittanbieter-Bibliotheken
• Bevorzugung aktiv gepflegter Projekte mit transparentem Security-Prozess

Schwachstellenerkennung

Patch Management

Secure Development

Für Eigenentwicklungen gelten:

• Security by Design – Sicherheitsanforderungen ab Entwurfsphase
• Code-Review – Vier-Augen-Prinzip für sicherheitsrelevante Änderungen
• Automatisierte Tests – Lint, Build, Security-Scan in CI/CD-Pipeline
• Dependency-Pinning – Versionierte und geprüfte Abhängigkeiten

Coordinated Vulnerability Disclosure

Die BAUER GROUP unterstützt die koordinierte Offenlegung von Schwachstellen:

• Meldewege für externe Sicherheitsforscher dokumentiert
• Bearbeitungsfristen für gemeldete Schwachstellen definiert
• Abstimmung mit Entdeckern vor Veröffentlichung