The NIS2 Directive (Directive (EU) 2022/2555) requires essential and important entities across 18 EU sectors to implement cybersecurity risk management measures under Article 21 and report significant incidents within 24 hours under Article 23, with administrative fines reaching €10 million or 2% of global annual turnover for non-compliance.
- How to identify whether your audit client falls within NIS2 scope and what that means for your risk assessment under ISA 315.9
- What Article 21’s ten minimum cybersecurity measures mean for your evaluation of IT general controls
- How to document NIS2 non-compliance as a potential subsequent event or going concern indicator under ISA 570.16
- Where NIS2 obligations create supply chain audit considerations under ISA 402
Why NIS2 changes the audit risk assessment
NIS2 replaced the original NIS Directive (Directive (EU) 2016/1148) in October 2024. The scope expansion alone is significant: where NIS1 covered a narrow set of operators of essential services, NIS2 pulls in 18 sectors and applies a size-based threshold (medium-sized enterprises with 50+ employees or €10M+ turnover). The European Commission estimated that the Directive brings approximately 160,000 entities across the EU into scope. In the Netherlands specifically, an estimated 8,000 organisations will fall under the Cyberbeveiligingswet (Cbw).
For auditors, the relevance isn’t abstract. NIS2 creates a regulatory compliance layer that can trigger material financial consequences.
Article 34 introduces administrative fines of up to €10 million or 2% of worldwide annual turnover for essential entities that fail to comply with Article 21’s risk management measures. That’s a contingent liability you need to assess. If your client is in scope and hasn’t implemented the required measures, you’re looking at a potential provision under IAS 37 or, at minimum, a disclosure consideration.
The Cbw is expected to enter into force in Q2 2026. The bill is currently in parliamentary review, with a plenary debate scheduled for March 2026. Even though formal enforcement hasn’t started in the Netherlands, the Rijksoverheid has explicitly advised organisations not to wait. Your 2025 and 2026 audits need to reflect the regulatory exposure regardless of the transposition timeline.
Which clients fall within NIS2 scope
NIS2 distinguishes between two tiers. Essential entities (Annex I sectors) face proactive supervision from national authorities, including regular audits. Important entities (Annex II sectors) face reactive supervision (enforcement after a suspected violation) but must still comply with the same Article 21 obligations. The practical difference: essential entities should expect inspections before anything goes wrong.
Annex I covers energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, and public administration. Annex II adds postal services, waste management, chemical manufacturing, food production, medical device manufacturing, digital providers such as online marketplaces, and manufacturing of computer and electronic products. The size threshold is a medium enterprise: 50 or more employees, or annual turnover exceeding €10M with a balance sheet above €10M. Member states can also designate smaller entities whose services are critical to national security.
For a practical scoping exercise during audit planning, you need two pieces of information: the client’s sector classification under the NIS2 annexes, and whether they meet the size threshold. If both conditions are met, NIS2 is in scope. Document this in your risk assessment working papers under ISA 315.9.
What Article 21 requires and how it connects to ITGCs
Article 21(2) prescribes ten minimum cybersecurity risk management measures. These aren’t optional guidance. They form the baseline that regulators will assess. The ten measures are:
- Policies on risk analysis and information system security
- Incident handling (prevention, detection, response, recovery)
- Business continuity and crisis management
- Supply chain security, including security-related aspects of relationships with direct suppliers
- Security in network and information system acquisition, development, maintenance, and vulnerability handling
- Policies and procedures to assess the effectiveness of cybersecurity risk management measures
- Basic cyber hygiene practices and cybersecurity training
- Policies on the use of cryptography and encryption
- Human resources security, access control policies, asset management, and data handling procedures
- Use of multi-factor authentication or continuous authentication solutions
If your audit approach relies on IT general controls, several of these overlap with your ITGC evaluation under ISA 315.A102-A107. Access control policies (measure 9) and MFA requirements (measure 10) connect to your assessment of logical access controls. Incident handling (measure 2) tells you whether the entity can detect unauthorised changes to financial data.
Business continuity (measure 3) relates to going concern if the entity depends on IT systems for revenue generation. The key point: NIS2 doesn’t create parallel audit work. It adds regulatory weight to controls you’re already testing.
If your client’s access controls are weak, that’s both an ITGC deficiency and a potential NIS2 violation. The audit consequence stays the same (reliance on IT controls may not be appropriate). But the regulatory consequence adds fines, remediation costs, potential personal liability for board members under Article 20, and reputational damage that could affect customer retention.
Article 20 deserves separate attention. It places explicit accountability on the management body for approving and overseeing Article 21 measures. Board members must also undergo cybersecurity training. This is a governance consideration for your understanding of the entity’s control environment under ISA 315.14. When the board hasn’t approved cybersecurity risk management measures and can’t demonstrate training, that’s a gap in the control environment that affects your overall risk assessment.
The incident reporting obligation and its audit trail
Article 23 establishes a tiered reporting obligation for significant incidents. An early warning goes to the national CSIRT (in the Netherlands, the NCSC) within 24 hours. A full notification follows within 72 hours, then a final report with root cause analysis within one month.
An incident qualifies as “significant” if it may lead to severe operational disruption or considerable financial loss. The Commission Implementing Regulation (EU) 2024/2690 published in October 2024 adds sector-specific triggers for digital infrastructure providers: leaked trade secrets or successful unauthorised access to network systems both qualify.
What does this mean for your audit? Any significant cybersecurity incident during the reporting period could affect the financial statements directly. A ransomware attack that shuts down operations for two weeks has revenue implications requiring quantification. Compromised client data creates potential GDPR fines (running alongside NIS2 fines) and a contingent liability under IAS 37.14. The audit trail implications go further still.
The 24-hour reporting requirement also creates an audit trail that didn’t exist before NIS2. Your client should now maintain an incident register with timestamps, severity classifications, NCSC communication records, and documented remediation steps. Request this register. Its absence is itself an indicator that incident handling procedures (Article 21, measure 2) may not meet the standard.
For subsequent events under ISA 560.7, any significant cyber incident between the balance sheet date and the audit report date requires evaluation. Pre-existing control weaknesses revealed by an incident may qualify as adjusting events. A novel attack exploited after year-end is non-adjusting but requires disclosure under IAS 10.21 if material.
Supply chain cybersecurity and ISA 402 implications
Article 21(2)(d) requires entities to secure their supply chains, including evaluating cybersecurity practices of direct suppliers. Article 21(3) adds that entities must consider vulnerabilities specific to each supplier and the overall quality of their cybersecurity practices.
This connects directly to ISA 402. If your client uses a service organisation for payroll processing or cloud hosting of financial systems, and that service organisation falls within NIS2 scope, the cybersecurity posture of the service organisation becomes audit-relevant. Under ISA 402.9, you assess whether the services are relevant to your audit. Financial data stored on a NIS2-regulated cloud platform meets that test.
In practice, request the service organisation’s SOC 2 Type II report (or equivalent) and evaluate its cybersecurity controls against NIS2 Article 21. Without such a report, additional procedures under ISA 402.15 become necessary.
The dynamic reverses for clients that supply NIS2-regulated entities. Your client may face contractual cybersecurity requirements from their customers. Contract termination for non-compliance is a going concern indicator if the client depends on a small number of NIS2-regulated customers for significant revenue. A €30M contract with a hospital chain demanding ISO 27001 certification by year-end isn’t just operational. It’s a financial statement risk.
Worked example: Dijkstra Logistics B.V.
Client profile: Dijkstra Logistics B.V. is a Dutch road transport and warehousing company with €62M revenue, 280 employees, operating temperature-controlled supply chain services for pharmaceutical distributors. Classified as an “important entity” under NIS2 Annex I (transport sector).
Step 1: Scope assessment during planning
Dijkstra meets the NIS2 size threshold (280 employees, €62M revenue) and operates in Annex I sector 4 (transport).
Documentation note
Record in Section B of the planning file: “NIS2 (Directive 2022/2555) applies to Dijkstra as an important entity in the transport sector. The Cyberbeveiligingswet (Cbw) is expected Q2 2026. Article 21 risk management measures and Article 23 incident reporting obligations are relevant to the audit risk assessment.”
Step 2: Understanding IT general controls against Article 21
During your walkthrough of the warehouse management system (WMS) and fleet management platform, you note that WMS access uses single-factor authentication only. Article 21(2)(j) requires multi-factor authentication where appropriate. For a system processing pharmaceutical supply chain data, MFA is clearly appropriate.
Documentation note
Record in the ITGC working paper: “WMS access relies on single-factor authentication. This represents a potential non-compliance with NIS2 Article 21(2)(j). Risk: unauthorised changes to inventory records could occur without detection. Audit response: we will not rely on automated controls within the WMS. Substantive testing of inventory quantities at year-end will be performed instead.”
Step 3: Incident register review
You request Dijkstra’s cybersecurity incident register. The IT manager provides a spreadsheet with four entries from the audit period. One entry records a phishing attack that compromised an employee email account for 48 hours before detection. Nobody reported the incident to the NCSC.
Documentation note
“Phishing incident in September affected one user account with access to supplier payment authorisation workflows. Not reported to NCSC within 24 hours as required by NIS2 Article 23. Assess: (a) whether any fraudulent supplier payments were initiated from the compromised account (ISA 240.27), (b) whether non-reporting constitutes a NIS2 violation with potential fine exposure (IAS 37.14).”
Step 4: Supply chain assessment
Dijkstra’s largest customer (a pharmaceutical distributor classified as an essential entity) has issued a new cybersecurity addendum. It requires annual penetration testing and ISO 27001 certification by December 2026. Dijkstra holds neither. The contract represents 38% of revenue (€23.6M).
Documentation note
“Customer cybersecurity requirements linked to NIS2 supply chain obligations (Article 21(2)(d)). Non-compliance risk: termination of €23.6M revenue contract. Assess going concern implications under ISA 570.16. Request management’s certification plan with cost estimate and timeline. Document feasibility assessment.”
Conclusion: The file contains a NIS2 scope assessment, an ITGC finding with compensating audit response, a potential regulatory non-compliance with quantified fine exposure, and a going concern indicator linked to supply chain cybersecurity. A reviewer sees a connected, risk-responsive approach.
Practical checklist for your next engagement
- At planning, ask whether your client has completed the NIS2 self-assessment (the Dutch RDI publishes one at mijn.ncsc.nl). If they haven’t, perform your own scoping assessment using the Annex I and II sector lists against the size threshold. Document the result either way.
- Request the client’s cybersecurity risk management policy. Compare it against the ten minimum measures in Article 21(2). Any missing measure is an ITGC gap and a potential regulatory exposure.
- Request the cybersecurity incident register for the audit period. Check for incidents not reported within 24 hours and for incidents affecting systems that process financial data.
- For clients using service organisations within NIS2 scope, request an updated SOC 2 Type II report. Evaluate whether the testing period covers your audit period (ISA 402.12).
- Ask whether the management body has formally approved cybersecurity risk management measures and whether board members have completed cybersecurity training (Article 20). Note any gap.
- Quantify the maximum fine exposure (€10M or 2% of worldwide turnover, whichever is higher) and assess whether a provision or disclosure is required under IAS 37.
Common mistakes
- Treating cybersecurity as “IT’s problem” and excluding NIS2 from the audit risk assessment entirely. The AFM has flagged IT-related control deficiencies as a recurring finding area in non-Big 4 inspection files. NIS2 formalises what the AFM already expects: that auditors understand the IT control environment.
- Relying on the delayed Cyberbeveiligingswet (expected Q2 2026) as a reason to defer NIS2 considerations. Clients in sectors already covered by the previous Wbni face existing obligations under that regime. Regulatory fine exposure exists regardless of the Dutch transposition timeline.
- Failing to connect a cybersecurity incident to the financial statements. A two-week ransomware shutdown affects revenue recognition (IFRS 15.35) and inventory valuation (IAS 2.28 if perishable goods are affected). It may also trigger onerous contract provisions under IAS 37.66. This isn’t just an IT event.
Get practical audit insights, weekly.
No exam theory. Just what makes audits run faster.
No spam — we're auditors, not marketers.
Related content
Frequently asked questions
Does NIS2 apply to my audit client?
NIS2 applies to entities in 18 EU sectors (energy, transport, banking, health, digital infrastructure, and more) that meet the size threshold of 50 or more employees or annual turnover exceeding €10M. Check whether your client’s sector falls within Annex I (essential entities) or Annex II (important entities) and whether they meet the size criteria. Document the result in your ISA 315 risk assessment.
What are the maximum fines under NIS2?
Article 34 introduces administrative fines of up to €10 million or 2% of worldwide annual turnover for essential entities that fail to comply with Article 21’s cybersecurity risk management measures. This creates a contingent liability that auditors must assess under IAS 37.
How does NIS2 affect IT general controls testing?
Several of Article 21’s ten minimum cybersecurity measures overlap with ITGC evaluation under ISA 315.A102-A107. Access control policies, MFA requirements, and incident handling procedures are both NIS2 obligations and audit-relevant controls. NIS2 adds regulatory weight to controls you’re already testing.
What is the NIS2 incident reporting obligation?
Article 23 requires entities to send an early warning to the national CSIRT within 24 hours of a significant incident, a full notification within 72 hours, and a final report with root cause analysis within one month. This creates an audit trail (incident register) that auditors should request and review.
When does the Dutch Cyberbeveiligingswet (Cbw) take effect?
The Cbw is expected to enter into force in Q2 2026. The bill is currently in parliamentary review. However, the Rijksoverheid has advised organisations not to wait, and regulatory fine exposure exists regardless of the Dutch transposition timeline for clients in sectors already covered by the previous Wbni.
Further reading and source references
- Directive (EU) 2022/2555 (NIS2): Articles 20, 21, 23, and 34 on governance, risk management measures, incident reporting, and administrative fines.
- Commission Implementing Regulation (EU) 2024/2690: sector-specific incident triggers for digital infrastructure providers.
- ISA 315 (Revised 2019): paragraphs 9, 14, and A102-A107 on understanding the entity’s IT environment and control environment.
- ISA 402: paragraphs 9 and 15 on audit considerations for service organisations.
- IAS 37: paragraphs 14 and 86 on provisions, contingent liabilities, and disclosure requirements.
- ISA 560: paragraph 7 on subsequent events evaluation.