--- title: "Audit-Vorbereitung NIS2: Checkliste für IT-Leiter" date: 2026-02-03T09:50:00+01:00 author: FAST LTA canonical_url: "https://www.fast-lta.de/de/blog/audit-vorbereitung-nis2-checkliste" section: "Entries: Articles" --- ### 1. Was NIS2-Audits von klas­si­schen IT-Audits unter­schei­det [\#](#1-was-nis2-audits-von-klassischen-it-audits-unterscheidet "1. Was NIS2-Audits von klassischen IT-Audits unterscheidet") 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 [\#](#2-checkliste-30-bsig-alle-pr%C3%BCfbereiche "2. Checkliste: §30 BSIG, alle Prüfbereiche") #### Bereich 1: Risi­ko­ana­ly­se und Sicher­heits­kon­zep­te [\#](#bereich-1-risikoanalyse-und-sicherheitskonzepte "Bereich 1: Risikoanalyse und Sicherheitskonzepte") **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 [\#](#bereich-2-incident-handling-und-meldepflicht "Bereich 2: Incident Handling und Meldepflicht") **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 [\#](#bereich-3-backup-management-und-wiederherstellung "Bereich 3: Backup-Management und Wiederherstellung") 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 [\#](#bereich-4-business-continuity-und-krisenmanagement "Bereich 4: Business Continuity und Krisenmanagement") **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 [\#](#bereich-5-sicherheit-der-lieferkette "Bereich 5: Sicherheit der Lieferkette") **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 [\#](#bereich-6-technische-sicherheitsma%C3%9Fnahmen-und-schwachstellenmanagement "Bereich 6: Technische Sicherheitsmaßnahmen und Schwachstellenmanagement") **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 [\#](#bereich-7-schulungen-und-cyberhygiene "Bereich 7: Schulungen und Cyberhygiene") **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 [\#](#bereich-8-verschl%C3%BCsselung-und-kryptografie "Bereich 8: Verschlüsselung und Kryptografie") **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 [\#](#3-die-10-h%C3%A4ufigsten-auditbefunde-und-wie-man-sie-vermeidet "3. Die 10 häufigsten Auditbefunde und wie man sie vermeidet") - **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 [\#](#4-zeitplan-was-wann-bereit-sein-muss "4. Zeitplan: 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 [\#](#5-audit-tag-was-sie-bereithalten-m%C3%BCssen "5. Audit-Tag: Was Sie bereithalten müssen") 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 [\#](#weiterf%C3%BChrende-ressourcen "Weiterführende Ressourcen") → 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/) ### Disaster Recovery Disaster Recovery bezeichnet die strukturierten Prozesse und technischen Maßnahmen, die sicherstellen, dass IT-Systeme nach einem schwerwiegenden Ausfall — Ransomware-Angriff, Hardwareversagen, Rechenzentrumsausfall — innerhalb definierter Zeitrahmen (RTO) mit maximalem Datenverlust (RPO) wiederhergestellt werden können. [Mehr erfahren →](https://www.fast-lta.de/de/glossar/disaster-recovery) ### Disaster Recovery Disaster Recovery bezeichnet die strukturierten Prozesse und technischen Maßnahmen, die sicherstellen, dass IT-Systeme nach einem schwerwiegenden Ausfall — Ransomware-Angriff, Hardwareversagen, Rechenzentrumsausfall — innerhalb definierter Zeitrahmen (RTO) mit maximalem Datenverlust (RPO) wiederhergestellt werden können. [Mehr erfahren →](https://www.fast-lta.de/de/glossar/disaster-recovery) ### Disaster Recovery Disaster Recovery bezeichnet die strukturierten Prozesse und technischen Maßnahmen, die sicherstellen, dass IT-Systeme nach einem schwerwiegenden Ausfall — Ransomware-Angriff, Hardwareversagen, Rechenzentrumsausfall — innerhalb definierter Zeitrahmen (RTO) mit maximalem Datenverlust (RPO) wiederhergestellt werden können. [Mehr erfahren →](https://www.fast-lta.de/de/glossar/disaster-recovery) ### Disaster Recovery Disaster Recovery bezeichnet die strukturierten Prozesse und technischen Maßnahmen, die sicherstellen, dass IT-Systeme nach einem schwerwiegenden Ausfall — Ransomware-Angriff, Hardwareversagen, Rechenzentrumsausfall — innerhalb definierter Zeitrahmen (RTO) mit maximalem Datenverlust (RPO) wiederhergestellt werden können. [Mehr erfahren →](https://www.fast-lta.de/de/glossar/disaster-recovery) ### Disaster Recovery Disaster Recovery bezeichnet die strukturierten Prozesse und technischen Maßnahmen, die sicherstellen, dass IT-Systeme nach einem schwerwiegenden Ausfall — Ransomware-Angriff, Hardwareversagen, Rechenzentrumsausfall — innerhalb definierter Zeitrahmen (RTO) mit maximalem Datenverlust (RPO) wiederhergestellt werden können. [Mehr erfahren →](https://www.fast-lta.de/de/glossar/disaster-recovery) ### Business Continuity Management Business Continuity Management (BCM) ist der organisatorische Rahmen, der sicherstellt, dass kritische Geschäftsprozesse auch bei schwerwiegenden IT-Ausfällen, Cyberangriffen oder anderen Krisen aufrechterhalten oder in definierten Zeitrahmen wiederhergestellt werden können. [Mehr erfahren →](https://www.fast-lta.de/de/glossar/business-continuity-management)