NIS2 Article 21 and 23: Incident Reporting and Supply Chain Security Need More Than an ISMS
2026-01-06
By Anna Bley
NIS2
Security
Compliance

NIS2 Article 21 and 23: Incident Reporting and Supply Chain Security Need More Than an ISMS

NIS2 Article 21 and 23 require operational incident reporting (24h and 72h) and supply chain risk management. An ISMS helps governance, but not day to day execution.

NIS2 Article 21 and 23: Incident Reporting and Supply Chain Security Need More Than an ISMS

The NIS2 Directive has set clear rules for managing cybersecurity risks, including strict incident reporting deadlines: 24 hours for an early warning and 72 hours for a formal notification. For many organizations, this raises a pressing question: Is the existing Information Security Management System still sufficient – or does it take more?

An ISMS and ISO 27001 structure internal governance. Trust Centers handle the operational side: vendor and incident management as required by Articles 21 and 23.

Jump to:


Why an ISMS Is No Longer Enough Under NIS2

Many organizations today have an Information Security Management System (ISMS): aligned with ISO 27001, often embedded in a GRC tool – complete with policies, risk registers, controls, and annual audits. An ISMS is valuable and provides a solid foundation for NIS2 compliance.

However, NIS2 introduces a paradigm shift that many companies are only gradually coming to terms with. It moves the focus away from "we have an ISMS, everything is documented" toward "we demonstrably practice cybersecurity, can respond adequately to time-critical events, and have continuous visibility into our supply chain" – all under the explicit responsibility of executive management.

This shift is evident in the directive's language: it requires "appropriate and proportionate technical, operational and organisational measures" (Article 21) – measures that manage risk and minimize the impact of incidents. The word "operational" is where most ISMS solutions fall short: they enable good documentation but don't function as a robust operating system. What's missing: communication of security incidents, ongoing monitoring of supplier security, and evidence of effectiveness that's available on demand – for regulators, for instance.

In Germany, NIS2 is now binding law: the implementing legislation was published in the Federal Law Gazette and entered into force on December 6, 2025, with no transition period. This affects registration requirements for approximately 30,000 organizations and defines specific areas of action for managing cybersecurity risks.


Where an ISMS Contributes to NIS2 – Governance (Article 20)

In brief: A well-implemented ISMS delivers the governance structure that NIS2 requires for managing cybersecurity risks.

Article 20(1) makes governance explicitly a leadership responsibility – executive management must approve the measures under Article 21, oversee their implementation, and bear personal liability for violations.

An ISMS supports exactly this. It typically includes:

  • Responsibilities, roles, and escalation paths
  • Policies and processes for assessing risks and risk measures
  • Risk management and asset management
  • Audit checklists and documentation for external audit preparation
  • Awareness and training programs
  • Internal reviews and audits to optimize processes

Article 21 explicitly lists requirements such as "(a) policies on risk analysis, (c) business continuity, (f) policies and processes to assess the effectiveness of cybersecurity risk-management measures, and (g) cybersecurity training" – all of which can be effectively addressed through an ISMS.

Beyond this, NIS2 introduces requirements with an interface character – such as supply chain security assessments and incident reporting – that an ISMS, as an internal solution, simply cannot cover.


Where NIS2 Goes Beyond an ISMS: Vendor and Incident Management (Articles 21 and 23)

In brief: NIS2 expects more than governance: operational management of supply chain risks, continuous monitoring, and structured incident reporting.

Article 23: Incident reporting is an operational system, not a PDF

NIS2 explicitly requires measures for handling security incidents under Article 21(2)(b). Article 23 introduces a tiered reporting regime with tight deadlines: under points 4(a), (b), and (c), an early warning must be issued within 24 hours and a formal incident notification within 72 hours of becoming aware of the incident. Authorities may also request interim status reports and updates.

This is where the gap becomes visible: between companies that can say "we have an incident response plan" and those that can deliver "we can provide you with a fact-based report within 24 hours." Suddenly, answering substantive questions becomes urgent and critical:

  • What happened? How severe is the incident?
  • What impact could it have, and what are our indicators?
  • Who decides what, and based on what evidence?
  • How do Security, Legal, PR, Customer Support, and executive management coordinate?
  • How is communication documented and versioned – in a way that's traceable and auditable?

An ISMS documents incidents – usually after the fact. But NIS2 evaluates the operational capability to respond reliably under pressure – and that only works with a functioning incident management system.

Article 21: Supply chain security is a must-have

NIS2 explicitly mandates measures to ensure supply chain security under Article 21(1)(d). This specifically includes security-relevant aspects of relationships with direct suppliers and service providers.

Many ISMS solutions enable point-in-time vendor assessments – during onboarding or once a year. But NIS2 means something different: it's not about filling out supplier questionnaires and filing them away.

It's about keeping business-critical risks from dependencies manageable – especially in a geopolitical reality that's constantly shifting. This inevitably requires a continuously maintainable interface with service providers and suppliers.

Real vendor management means: ongoing monitoring with analytics, low-effort re-assessments when things change, integrated evidence, and fast communication when the situation evolves.

3. The Effort for Proving Effectiveness and Audit-Readiness Becomes Real (Article 21)

Article 21 explicitly requires internal policies and procedures to assess the effectiveness of risk measures. At the same time, NIS2 expands external oversight: authorities can conduct on-site inspections, audits, and scans – and, most importantly, request information at any time.

Evidence is no longer "audit decoration" – it's continuous output of ongoing work. Specifically, this requires:

  • Verifiable artifacts such as systems and logs – documents or assertions alone won't suffice
  • Artifacts need metadata: version status, validity, owners, change history
  • The ability to demonstrate controls, current vendor assessments, incident reports, and resilience to auditors at any time

All of this comes with real consequences: violations of Articles 21 or 23 can result in fines of up to EUR 10 million or 2% of global annual turnover for essential entities, and up to EUR 7 million or 1.4% for important entities.


ISMS and Trust Center: Two Sides of the Same Coin

NIS2 requirements cannot be met with a single system. Governance needs structure – an ISMS is essential for that. But Articles 21 and 23 also demand operational capabilities: rapid incident response, continuous supply chain oversight, and reliable evidence on demand.

Organizations that connect both worlds are well positioned: an ISMS for internal control, a Trust Center for external communication and evidence. This turns compliance effort into a functioning system – and documentation into real resilience.