--- title: "NIS2 Audit Preparation: Checklist for IT Managers" date: 2026-02-03T09:50:00+01:00 author: FAST LTA canonical_url: "https://www.fast-lta.de//en/blog/audit-vorbereitung-nis2-checkliste" section: "Entries: Articles" --- ### 1. What Makes NIS2 Audits Different from Standard IT Audits [\#](#1-what-makes-nis2-audits-different-from-standard-it-audits "1. What Makes NIS2 Audits Different from Standard IT Audits") NIS2 audits are not paper checks. Supervisory authorities do not merely verify that documents exist; they check whether described measures have been technically implemented and demonstrably tested. Three key differences from traditional IT compliance audits: **Evidence-based.** Auditors require logs, test records, screenshots, configuration evidence. A document that describes what should exist, without evidence of what does exist, is insufficient. **Management accountability.** Article 20 of the directive obligates management to approve risk management measures, monitor their implementation, and attend training. Auditors ask about board resolutions, management reviews, and escalation pathways. **Continuous improvement.** One-time measures are insufficient. Auditors ask when the DR plan was last tested, when the backup concept was last updated, when training last occurred. --- ### 2. Checklist: All Audit Areas Under Article 21 [\#](#2-checklist-all-audit-areas-under-article-21 "2. Checklist: All Audit Areas Under Article 21") #### Area 1: Risk Analysis and Security Concepts [\#](#area-1-risk-analysis-and-security-concepts "Area 1: Risk Analysis and Security Concepts") **What auditors check:** - Is there a current risk analysis for all critical systems? - Are risks prioritised and linked to mitigation measures? - Has the risk analysis been updated within the last 12 months? **Checklist:** - Risk analysis for all critical IT systems documented (date, methodology, findings) - Risk assessment by confidentiality, integrity, availability - Treatment plan for identified risks with owners and deadlines - Risk analysis reviewed and approved at least annually - Management has documented acknowledgment of the risk analysis **Common audit finding:** the risk analysis exists but is three years old and was never updated after the last data centre migration. --- #### Area 2: Incident Handling and Reporting Obligations [\#](#area-2-incident-handling-and-reporting-obligations "Area 2: Incident Handling and Reporting Obligations") **What auditors check:** - Is there an incident response plan with defined roles? - Are incidents detected, classified, and escalated? - Are the national reporting obligations known and embedded in processes? **Reporting deadlines under NIS2 (EU-wide):** - Early warning: within 24 hours, to the competent national authority or CSIRT (in Germany, for example, via the BSI reporting portal) - Incident notification: within 72 hours - Final report: within 1 month of the notification **Checklist:** - Incident response plan documented in writing - Roles in the IR plan assigned and known: incident commander, IT forensics, communications, legal - National reporting portal known; credentials registered and tested - 24-hour escalation path functions without dependency on IT infrastructure (if systems are down: how does the notification go out?) - Criteria for ​“significant incident” internally defined and communicated - Last incident response test (tabletop or live exercise) documented **Common audit finding:** the IR plan exists but contains phone numbers of employees who have left. Last test: unknown. --- #### Area 3: Backup Management and Recovery [\#](#area-3-backup-management-and-recovery "Area 3: Backup Management and Recovery") This area is consistently the most frequent weakness in NIS2 audits. **What auditors check:** - Is there a documented backup concept (in Germany, alignment with BSI module CON.3 is the customary reference; ISO 27001 Control 8.13 serves the same role internationally)? - Are backups performed regularly, and regularly tested? - Is at least one backup copy physically isolated from the production network? - Are RTO and RPO defined per critical system and verified through tests? **Checklist:** - Backup concept documented and current - RPO and RTO documented for all critical systems - Backup frequency aligned with RPO targets (daily backup for RPO of 24h; hourly for RPO of 1h) - At least one backup copy offline or physically isolated from the production network (air gap) - Recovery test records for the last four quarters available - Last test: full restore of a critical system with measured restore time - Restore time within the documented RTO - Backup systems managed with separate administrator accounts - Backup success rate monitored; failures escalated immediately **Audit question you must be prepared for:** ​“Please show me the record of the last full recovery test of critical system X. When was that? How long did the restore take? Were you within your RTO?” --- #### Area 4: Business Continuity and Crisis Management [\#](#area-4-business-continuity-and-crisis-management "Area 4: Business Continuity and Crisis Management") **Checklist:** - Business Impact Analysis (BIA) completed for all critical business processes - Maximum Tolerable Downtime (MTD) documented per process - Business Continuity Plan documented in writing with date of last revision - Crisis management team defined with deputy arrangements - Emergency communication plan: who informs whom, how (even when IT systems are down) - BCP test (tabletop or live) conducted and documented within the last 12 months - DR plan available offline (printed and secured, or encrypted on media independent of the network) **Common audit finding:** the BCP exists as a document but has never been tested. Staff do not know their roles in a crisis. The emergency contact list contains outdated numbers. --- #### Area 5: Supply Chain Security [\#](#area-5-supply-chain-security "Area 5: Supply Chain Security") **Checklist:** - Inventory of critical IT suppliers (hardware, software, cloud services, managed services) - Security evaluation of critical suppliers (questionnaires, certifications, audit rights) - Contractual cybersecurity requirements included in new supplier contracts - Failure of a critical supplier addressed as a scenario in the BCP - Cloud dependencies assessed: what happens if a cloud provider fails or is unavailable? - Hardware origin assessed: supply chain security for components of critical systems **Important:** for the backup area, this means the backup hardware manufacturer is a critical supplier. Their failure scenario and supply chain must be evaluated. --- #### Area 6: Technical Security Measures and Vulnerability Management [\#](#area-6-technical-security-measures-and-vulnerability-management "Area 6: Technical Security Measures and Vulnerability Management") **Checklist:** - Patch management process documented: critical patches within how many days? - Vulnerability scans conducted regularly (at least quarterly) with documented results - MFA enforced for all privileged accounts (admin, backup admin, firewall admin) - MFA enforced for remote access (VPN, RDP) - Network segmentation in place: backup systems in a separate VLAN or segment - Endpoint protection (EDR/XDR) active on all critical systems - Centralised log collection and SIEM for security-relevant events --- #### Area 7: Training and Cyber Hygiene [\#](#area-7-training-and-cyber-hygiene "Area 7: Training and Cyber Hygiene") **Checklist:** - Security training for all employees at least annually (evidence: participant records) - Management training conducted and documented (an explicit NIS2 duty) - Phishing simulations conducted and documented regularly - IT security policy communicated and acknowledged by employees --- #### Area 8: Cryptography and Encryption [\#](#area-8-cryptography-and-encryption "Area 8: Cryptography and Encryption") **Checklist:** - Encryption standards documented (AES-256 for data at rest; TLS 1.2+ for transmission) - Backup data encrypted at rest - Key management documented: where are encryption keys stored? - Keys available offline (if IT is down: can the restore still be decrypted?) --- ### 3. The 10 Most Common Audit Findings, and How to Prevent Them [\#](#3-the-10-most-common-audit-findings-and-how-to-prevent-them "3. The 10 Most Common Audit Findings, and How to Prevent Them") 1. **No recovery test records.** Root cause: ​“haven’t had time”. Remedy: schedule four quarterly tests per year; make the protocol mandatory. 2. **Outdated DR plan.** Never updated after the last infrastructure change. Remedy: enforce an annual review. 3. **No offline backup copy.** All backups on networked systems. Remedy: introduce an air gap layer (for example with the Silent Brick System). 4. **Backup managed with production credentials.** A single admin account for everything. Remedy: create dedicated backup admin accounts. 5. **IR plan missing reporting obligations.** Created before NIS2. Remedy: update the IR plan with the 24h/​72h/​1‑month deadlines. 6. **No BIA conducted.** BCM treated as optional. Remedy: run the BIA as a project; present findings to management. 7. **No SIEM, no centralised logging.** No previous pressure. Remedy: minimum implementation of log aggregation plus alerting. 8. **MFA not enforced.** VPN with password only. Remedy: enforce MFA for all privileged access within 30 days. 9. **Supplier risk unknown.** No inventory. Remedy: inventory critical suppliers; send security questionnaires. 10. **No training records.** Training conducted verbally. Remedy: digital confirmations, an LMS, or signed attendance sheets. --- ### 4. Timeline: What Must Be Ready and When [\#](#4-timeline-what-must-be-ready-and-when "4. Timeline: What Must Be Ready and When") - **Registration with the national authority:** already due in most member states (in Germany, the deadline was 6 March 2026). Register immediately if not yet done. Priority: critical. - **Technical measures under Article 21:** the obligation applies now and is ongoing. Priority: critical. - **Documented backup concept:** before the first audit. Priority: high. - **Most recent recovery test record:** before the first audit. Priority: high. - **Business Continuity Plan:** before the first audit. Priority: high. - **Air gap layer (if missing):** plan 4 to 8 weeks implementation time. Priority: high. - **Training records:** ongoing, at least annually. Priority: medium. --- ### 5. Audit Day: What to Have Ready [\#](#5-audit-day-what-to-have-ready "5. Audit Day: What to Have Ready") Prepare these documents for the audit day, printed or immediately accessible: 1. Backup concept (current, date visible) 2. Recovery test records for the last four quarters 3. Business Continuity Plan with date of last revision 4. Incident Response Plan with current contact details 5. Risk analysis with date and management sign-off 6. Supplier evaluations for critical IT providers 7. Proof of registration with the national authority 8. Training records (last year) 9. Patch management documentation (last quarter) 10. Network documentation and segmentation evidence --- ### Further Resources [\#](#further-resources "Further Resources") → NIS2 and IT Resilience: What the Directive Requires (/en/blog/nis2-it-resilienz-anforderungen/) → IT Resilience Guide (/en/blog/it-resilienz-leitfaden/) → Tabletop Exercise Ransomware: Instructions and Scenarios (/en/blog/tabletop-exercise-ransomware/) → From Level 2 to Level 4: The Most Efficient Path to Resilience (/en/blog/from-level-2-to-level-4-resilience/) → Silent Brick System (/en/produkte/silent-brick-system/) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### Business Continuity Management Business Continuity Management (BCM) is the organizational framework that ensures critical business processes can be maintained or restored within defined timeframes even during severe IT failures, cyber attacks or other crises. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/business-continuity-management) ### Ransomware Ransomware is malware that encrypts data on infected systems and demands a ransom for decryption — with the goal of forcing organizations and public bodies to pay by paralyzing their operations. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/ransomware) ### Business Continuity Management Business Continuity Management (BCM) is the organizational framework that ensures critical business processes can be maintained or restored within defined timeframes even during severe IT failures, cyber attacks or other crises. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/business-continuity-management) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### Business Continuity Management Business Continuity Management (BCM) is the organizational framework that ensures critical business processes can be maintained or restored within defined timeframes even during severe IT failures, cyber attacks or other crises. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/business-continuity-management) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### Business Continuity Management Business Continuity Management (BCM) is the organizational framework that ensures critical business processes can be maintained or restored within defined timeframes even during severe IT failures, cyber attacks or other crises. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/business-continuity-management)