Audit-Vorbereitung NIS2: Checkliste für IT-Leiter

1. Was NIS2-Audits von klas­si­schen IT-Audits unter­schei­det #

NIS2-Prü­fun­gen sind kei­ne Papier­checks. Das BSI prüft nicht nur, ob Doku­men­te exis­tie­ren. Es prüft, ob die beschrie­be­nen Maß­nah­men tech­nisch umge­setzt und nach­weis­lich getes­tet wurden.

Drei Unter­schie­de gegen­über klas­si­schen IT-Compliance-Prüfungen:

Evi­denz­ba­siert: Audi­to­ren ver­lan­gen Logs, Test­pro­to­kol­le, Screen­shots, Kon­fi­gu­ra­ti­ons­nach­wei­se. Ein Doku­ment, das beschreibt, was sein soll­te, ohne Bele­ge, was ist, reicht nicht.

Manage­ment­ver­ant­wor­tung: §38 BSIG ver­pflich­tet die Geschäfts­lei­tung, Risi­ko­ma­nage­ment­maß­nah­men zu bil­li­gen, ihre Umset­zung zu über­wa­chen und selbst an Schu­lun­gen teil­zu­neh­men. Audi­to­ren fra­gen nach Vor­stands­be­schlüs­sen, Manage­ment-Reviews und Eskalationswegen.

Kon­ti­nu­ier­li­che Ver­bes­se­rung: Ein­ma­li­ge Maß­nah­men rei­chen nicht. Prü­fer fra­gen, wann der DR-Plan zuletzt getes­tet, wann das Daten­si­che­rungs­kon­zept zuletzt aktua­li­siert wur­de, wann zuletzt Schu­lun­gen stattfanden.

---

2. Check­lis­te: §30 BSIG, alle Prüf­be­rei­che #

Bereich 1: Risi­ko­ana­ly­se und Sicher­heits­kon­zep­te #

Was Audi­to­ren prüfen:

• Exis­tiert eine aktu­el­le Risi­ko­ana­ly­se für alle kri­ti­schen Systeme?
• Sind Risi­ken prio­ri­siert und mit Maß­nah­men hinterlegt?
• Wur­de die Risi­ko­ana­ly­se in den letz­ten 12 Mona­ten aktualisiert?

Check­lis­te:

• Risi­ko­ana­ly­se aller kri­ti­schen IT-Sys­te­me doku­men­tiert (Datum, Metho­dik, Ergebnis)
• Risi­ko­be­wer­tung nach Ver­trau­lich­keit, Inte­gri­tät, Verfügbarkeit
• Behand­lungs­plan für iden­ti­fi­zier­te Risi­ken mit Ver­ant­wort­li­chen und Terminen
• Risi­ko­ana­ly­se regel­mä­ßig (min­des­tens jähr­lich) über­prüft und freigegeben
• Geschäfts­lei­tung hat Risi­ko­ana­ly­se doku­men­tiert zur Kennt­nis genommen

Typi­scher Audit­be­fund: Risi­ko­ana­ly­se exis­tiert, ist aber 3 Jah­re alt und wur­de nach dem letz­ten Umzug ins neue Rechen­zen­trum nie aktualisiert.

---

Bereich 2: Inci­dent Hand­ling und Mel­de­pflicht #

Was Audi­to­ren prüfen:

• Exis­tiert ein Inci­dent-Respon­se-Plan mit defi­nier­ten Rollen?
• Wer­den Vor­fäl­le erkannt, klas­si­fi­ziert und eskaliert?
• Sind die Mel­de­pflich­ten an das BSI bekannt und in Pro­zes­sen verankert?

Mel­de­pflich­ten im Überblick:

• Früh­war­nung an das BSI: inner­halb von 24 Stun­den nach Kennt­nis eines erheb­li­chen Vorfalls
• Mel­dung mit ers­ter Bewer­tung: inner­halb von 72 Stunden
• Abschluss­be­richt: spä­tes­tens 1 Monat nach der Meldung

Check­lis­te:

• Inci­dent-Respon­se-Plan schrift­lich dokumentiert
• Rol­len im IR-Plan besetzt und bekannt: Inci­dent Com­man­der, IT-Foren­sik, Kom­mu­ni­ka­ti­on, Rechtsabteilung
• BSI-Mel­de­ver­fah­ren bekannt; Zugang regis­triert und getestet
• 24-Stun­den-Eska­la­ti­ons­pfad ohne Abhän­gig­keit von IT-Infra­struk­tur (wenn Sys­te­me aus­ge­fal­len sind: wie geht die Mel­dung raus?)
• Kri­te­ri­en für ​„erheb­li­cher Vor­fall” intern defi­niert und kommuniziert
• Letz­ter Inci­dent-Respon­se-Test (Table­top oder Real-Test) dokumentiert

Typi­scher Audit­be­fund: IR-Plan exis­tiert, ent­hält aber Han­dy­num­mern von Mit­ar­bei­tern, die das Unter­neh­men ver­las­sen haben. Letz­ter Test: unbekannt.

---

Bereich 3: Back­up-Manage­ment und Wie­der­her­stel­lung #

Die­ser Bereich ist erfah­rungs­ge­mäß der häu­figs­te Schwach­punkt in NIS2-Prüfungen.

Was Audi­to­ren prüfen:

• Exis­tiert ein Daten­si­che­rungs­kon­zept nach BSI CON.3?
• Wer­den Back­ups regel­mä­ßig durch­ge­führt und regel­mä­ßig getestet?
• Ist min­des­tens eine Back­up-Kopie phy­sisch vom Pro­duk­ti­ons­netz getrennt?
• Sind RTO und RPO je kri­ti­sches Sys­tem defi­niert und durch Tests belegt?

Check­lis­te:

• Daten­si­che­rungs­kon­zept nach BSI CON.3 schrift­lich vor­han­den und aktuell
• RPO und RTO für alle kri­ti­schen Sys­te­me dokumentiert
• Back­up-Fre­quenz in Linie mit RPO-Zie­len (täg­li­ches Back­up bei RPO = 24 h; stünd­lich bei RPO = 1 h)
• Min­des­tens eine Back­up-Kopie off­line bezie­hungs­wei­se phy­sisch getrennt vom Pro­duk­ti­ons­netz (Air-Gap-Regel)
• Reco­very-Test-Pro­to­kol­le der letz­ten vier Quar­ta­le vorhanden
• Letz­ter Test: voll­stän­di­ger Res­to­re eines kri­ti­schen Sys­tems mit gemes­se­ner Restorezeit
• Res­to­re­zeit liegt inner­halb des doku­men­tier­ten RTO
• Back­up-Sys­te­me wer­den mit sepa­ra­ten Admi­nis­tra­tor­kon­ten verwaltet
• Back­up-Erfolgs­quo­te wird über­wacht; Feh­ler wer­den eskaliert

Audit-Fra­ge, auf die Sie vor­be­rei­tet sein müssen: ​„Bit­te zei­gen Sie mir das Pro­to­koll des letz­ten voll­stän­di­gen Reco­very-Tests von [kri­ti­schem Sys­tem X]. Wann war das? Wie lan­ge hat die Wie­der­her­stel­lung gedau­ert? Lagen Sie inner­halb Ihres RTO?”

---

Bereich 4: Busi­ness Con­ti­nui­ty und Kri­sen­ma­nage­ment #

Was Audi­to­ren prüfen:

• Exis­tiert ein Busi­ness Con­ti­nui­ty Plan (BCP)?
• Ist eine Busi­ness Impact Ana­ly­sis (BIA) durch­ge­führt worden?
• Wer­den Not­fall-Kom­mu­ni­ka­ti­ons­we­ge regel­mä­ßig getestet?

Check­lis­te:

• Busi­ness Impact Ana­ly­sis (BIA) für alle kri­ti­schen Geschäfts­pro­zes­se durchgeführt
• Maxi­mum Tole­ra­ble Down­ti­me (MTD) je Pro­zess dokumentiert
• Busi­ness Con­ti­nui­ty Plan schrift­lich vor­han­den, Datum der letz­ten Über­ar­bei­tung bekannt
• Kri­sen­ma­nage­ment-Team defi­niert mit Vertretungsregelungen
• Not­fall-Kom­mu­ni­ka­ti­ons­plan: Wer infor­miert wen wie (auch wenn IT-Sys­te­me aus­ge­fal­len sind)?
• BCP-Test (Table­top oder Real-Test) in den letz­ten 12 Mona­ten durch­ge­führt und dokumentiert
• DR-Plan ist off­line ver­füg­bar (gedruckt, im Tre­sor; oder ver­schlüs­selt auf Medi­um ohne Netzabhängigkeit)

Typi­scher Audit­be­fund: BCP exis­tiert als Doku­ment, wur­de aber nie getes­tet. Mit­ar­bei­ter ken­nen ihre Rol­le im Kri­sen­fall nicht. Not­fall-Kon­takt­lis­te ent­hält ver­al­te­te Nummern.

---

Bereich 5: Sicher­heit der Lie­fer­ket­te #

Was Audi­to­ren prüfen:

• Wer­den kri­ti­sche IT-Lie­fe­ran­ten und Dienst­leis­ter auf Sicher­heits­ri­si­ken bewertet?
• Exis­tie­ren ver­trag­li­che Anfor­de­run­gen an die Cyber­si­cher­heit von Lieferanten?
• Sind Abhän­gig­kei­ten von kri­ti­schen Ein­zel­lie­fe­ran­ten bekannt und bewertet?

Check­lis­te:

• Inven­tar kri­ti­scher IT-Lie­fe­ran­ten (Hard­ware, Soft­ware, Cloud-Diens­te, Mana­ged Services)
• Sicher­heits­be­wer­tung kri­ti­scher Lie­fe­ran­ten (Fra­ge­bö­gen, Zer­ti­fi­ka­te, Audit-Rechte)
• Ver­trag­li­che Cyber­si­cher­heits­an­for­de­run­gen in Neu­ver­trä­gen enthalten
• Aus­fall eines kri­ti­schen Lie­fe­ran­ten als Sze­na­rio im BCP berücksichtigt
• Cloud-Abhän­gig­kei­ten bewer­tet: Was pas­siert, wenn der Cloud-Anbie­ter aus­fällt oder gesperrt wird?
• Hard­ware-Her­kunft bewer­tet: Lie­fer­ket­ten­si­cher­heit für Kom­po­nen­ten kri­ti­scher Systeme

Wich­tig: Für den Back­up-Bereich bedeu­tet das: Der Back­up-Hard­ware-Her­stel­ler ist ein kri­ti­scher Lie­fe­rant. Des­sen Aus­fall­sze­na­rio und Lie­fer­ket­te müs­sen bewer­tet sein.

---

Bereich 6: Tech­ni­sche Sicher­heits­maß­nah­men und Schwach­stel­len­ma­nage­ment #

Was Audi­to­ren prüfen:

• Wer­den bekann­te Schwach­stel­len zeit­nah behoben?
• Ist Mul­ti-Fak­tor-Authen­ti­fi­zie­rung für pri­vi­le­gier­te Zugän­ge umgesetzt?
• Ist Netz­werk­seg­men­tie­rung vorhanden?

Check­lis­te:

• Patch-Manage­ment-Pro­zess doku­men­tiert: Kri­ti­sche Patches inner­halb wie vie­ler Tage?
• Schwach­stel­len­scans regel­mä­ßig (min­des­tens quar­tals­wei­se) und Ergeb­nis­se dokumentiert
• MFA für alle pri­vi­le­gier­ten Kon­ten (Admin, Back­up-Admin, Fire­wall-Admin) erzwungen
• MFA für Remo­te Access (VPN, RDP) erzwungen
• Netz­werk­seg­men­tie­rung vor­han­den: Back­up-Sys­te­me in eige­nem VLAN/​Segment
• End­punkt­schutz (EDR/XDR) auf allen kri­ti­schen Sys­te­men aktiv
• Zen­tra­le Log-Samm­lung und SIEM-Aus­wer­tung für sicher­heits­re­le­van­te Ereignisse

---

Bereich 7: Schu­lun­gen und Cyber­hy­gie­ne #

Check­lis­te:

• Sicher­heits­schu­lun­gen für alle Mit­ar­bei­ter min­des­tens jähr­lich (Nach­weis: Teilnehmerlisten)
• Phis­hing-Simu­la­tio­nen regel­mä­ßig durch­ge­führt und dokumentiert
• IT-Sicher­heits-Poli­cy kom­mu­ni­ziert und von Mit­ar­bei­tern bestätigt
• Schu­lung der Geschäfts­lei­tung: §38 BSIG ver­pflich­tet die Lei­tungs­ebe­ne zur Teil­nah­me an Schu­lun­gen; Nach­wei­se dokumentieren

---

Bereich 8: Ver­schlüs­se­lung und Kryp­to­gra­fie #

Check­lis­te:

• Ver­schlüs­se­lungs­stan­dards doku­men­tiert (AES-256 für ruhen­de Daten; TLS 1.2+ für Übertragung)
• Back­up-Daten im Ruhe­zu­stand verschlüsselt
• Schlüs­sel­ma­nage­ment doku­men­tiert: Wo wer­den Ver­schlüs­se­lungs­schlüs­sel aufbewahrt?
• Schlüs­sel off­line ver­füg­bar (wenn die IT aus­ge­fal­len ist: kann der Res­to­re trotz­dem ent­schlüs­selt werden?)

---

3. Die 10 häu­figs­ten Audit­be­fun­de und wie man sie ver­mei­det #

• Reco­very-Tests feh­len. Ursa­che: ​„Haben kei­ne Zeit gehabt.” Gegen­mit­tel: Kalen­der-Ein­trag, 4 Quar­tals­tests pro Jahr, Protokollpflicht.
• Ver­al­te­ter DR-Plan. Ursa­che: Plan nie aktua­li­siert nach letz­ter Infra­struk­tur­ver­än­de­rung. Gegen­mit­tel: jähr­li­cher Review-Termin.
• Kei­ne Off­line-Back­up-Kopie. Ursa­che: Back­up nur auf netz­ge­bun­de­nen Sys­te­men. Gegen­mit­tel: Air-Gap-Lay­er ein­füh­ren (Silent Brick System).
• Back­up mit Pro­duk­ti­ons-Cre­den­ti­als. Ursa­che: ein Admin-Kon­to für alles. Gegen­mit­tel: sepa­ra­te Back­up-Admin-Kon­ten einrichten.
• IR-Plan ohne Mel­de­pflich­ten. Ursa­che: Plan stammt aus der Zeit vor NIS2. Gegen­mit­tel: IR-Plan mit den BSIG-Mel­de­pflich­ten (24 h / 72 h / 1 Monat) aktualisieren.
• BIA nie durch­ge­führt. Ursa­che: BCM wird als optio­nal betrach­tet. Gegen­mit­tel: BIA als Pro­jekt auf­set­zen, Ergeb­nis dem Vor­stand vorlegen.
• Kein SIEM, kein SOC. Ursa­che: bis­her kein Druck. Gegen­mit­tel: Mini­mal­im­ple­men­tie­rung mit Log-Aggre­ga­ti­on und Alarmierung.
• MFA nicht erzwun­gen. Ursa­che: VPN nur mit Pass­wort. Gegen­mit­tel: MFA für alle pri­vi­le­gier­ten Zugän­ge bin­nen 30 Tagen.
• Lie­fe­ran­ten­ri­si­ko unbe­kannt. Ursa­che: kein Inven­tar. Gegen­mit­tel: kri­ti­sche Lie­fe­ran­ten inven­ta­ri­sie­ren, Fra­ge­bö­gen versenden.
• Schu­lungs­nach­wei­se feh­len. Ursa­che: Schu­lun­gen fan­den münd­lich statt. Gegen­mit­tel: digi­ta­le Bestä­ti­gun­gen, LMS-Sys­tem oder Unterschriftenlisten.

---

4. Zeit­plan: Was wann bereit sein muss #

• BSI-Regis­trie­rung (NIS2): Frist war der 6. März 2026. Falls noch nicht erfolgt: sofort nachholen.
• Tech­ni­sche Maß­nah­men nach §30 BSIG: Pflicht seit 6. Dezem­ber 2025, lau­fend. Prio­ri­tät: kritisch.
• Umset­zungs­nach­weis beson­ders wich­ti­ger Ein­rich­tun­gen: bis Dezem­ber 2028 gegen­über dem BSI. Wer erst 2028 anfängt, schafft den Nach­weis nicht.
• Daten­si­che­rungs­kon­zept BSI CON.3: vor der ers­ten Prü­fung. Prio­ri­tät: hoch.
• Reco­very-Test­pro­to­koll (letz­ter Test): vor der ers­ten Prü­fung. Prio­ri­tät: hoch.
• Busi­ness Con­ti­nui­ty Plan: vor der ers­ten Prü­fung. Prio­ri­tät: hoch.
• Air-Gap-Lay­er (wenn feh­lend): 4 bis 8 Wochen Umset­zungs­zeit ein­pla­nen. Prio­ri­tät: hoch.
• Schu­lungs­nach­wei­se: lau­fend, min­des­tens jähr­lich. Prio­ri­tät: mittel.

Hin­weis: BSI-Prü­fun­gen fin­den statt. Ein­rich­tun­gen, die auf den Prüf­ter­min war­ten, bevor sie han­deln, haben zu wenig Zeit für Maß­nah­men wie die Ein­füh­rung eines Air-Gap-Layers.

---

5. Audit-Tag: Was Sie bereit­hal­ten müs­sen #

Berei­ten Sie fol­gen­de Doku­men­te für den Audit-Tag vor, gedruckt oder sofort abrufbar:

1. Daten­si­che­rungs­kon­zept (aktu­ell, Datum sichtbar)
2. Reco­very-Test­pro­to­kol­le der letz­ten vier Quartale
3. Busi­ness Con­ti­nui­ty Plan mit Datum der letz­ten Aktualisierung
4. Inci­dent-Respon­se-Plan mit aktu­el­len Kontaktdaten
5. Risi­ko­ana­ly­se mit Datum und Frei­ga­be der Geschäftsleitung
6. Lie­fe­ran­ten­be­wer­tun­gen für kri­ti­sche IT-Anbieter
7. Nach­weis der BSI-Registrierung
8. Schu­lungs­nach­wei­se (letz­tes Jahr)
9. Patch-Manage­ment-Doku­men­ta­ti­on (letz­tes Quartal)
10. Netz­werk­do­ku­men­ta­ti­on und Segmentierungsnachweis

---

Wei­ter­füh­ren­de Res­sour­cen #

→ NIS2 und IT-Resi­li­enz: Was das Gesetz kon­kret for­dert (/de/­b­log/­nis2-it-resi­li­enz-anfor­de­run­gen/) → Back­up-Archi­tek­tur für KRI­TIS: Refe­renz­de­sign (/de/­b­log/­back­up-archi­tek­tur-kri­tis-refe­renz­de­si­gn/) → Table­top Exer­cise Ran­som­wa­re: Anlei­tung und Sze­na­ri­en (/de/­b­log/­ta­ble­top-exer­cise-ran­som­wa­re/) → IT-Resi­li­enz: Leit­fa­den für wider­stands­fä­hi­ge IT (/de/­b­log/it-resi­li­enz-leit­fa­den/)