NIS2 Art. 23 for Public Administration: GovCERT vs. CSIRT Routing, the Art. 2(7) Exclusion, and What Central Government Must Report

Most NIS2 guides treat Article 23 as a sector-agnostic timeline — 24 hours, 72 hours, one month. For private-sector essential entities, that framing is sufficient. For public administration bodies, it skips the foundational question.

Before a government CISO files a single Article 23 notification, two prior decisions must be made. The first: does NIS2 actually apply? Article 2(7) of the Directive excludes public administration entities whose activities fall within national security, public security, defence, or law enforcement. The second: where does the notification go? Most member states operate a dedicated government CSIRT — GovCERT Austria, Germany’s BSI with its separate Bundesbehörden reporting chain, NCSC-NL for Dutch central government — distinct from the national CSIRT that serves private-sector operators. Sending an Art. 23 report to the wrong authority, even within the correct 24-hour window, does not satisfy the notification obligation.

These two questions interact during a live incident in a way that creates real operational risk. When ransomware hits a ministry of internal affairs at 03:00, the CISO is simultaneously deciding whether the event triggers NIS2 at all, which authority receives the notification, and whether elements of the affected infrastructure cross the national security line that converts the incident from an Art. 23 compliance matter into a sovereign security escalation.

This article maps the Art. 2(7) scope threshold and Art. 2(8) optional exemption, explains the three-stage Art. 23 notification framework for in-scope public bodies, provides a country routing table for Germany, Austria, and the Netherlands, and closes with the documentation your competent authority inspector will ask to see first. For a deeper look at the general NIS2 scope framework and the public administration sector overview, those pages provide the wider context.

Does NIS2 Apply to Your Public Administration Body?

Plain-language summary: Central government bodies are subject to NIS2 with no size threshold. Bodies whose primary function is national security, public security, defence, or law enforcement are excluded outright. Mixed-function entities — those that do both civil administration and security work — sit in a legally ambiguous middle ground that requires active classification.

NIS2 places public administration at the essential entity tier under Annex I sector 10. Unlike private-sector entities — which must meet a 250-employee or €50 million turnover threshold to qualify as essential — central government bodies are in scope regardless of size. A 12-person ministry digital service unit carries the same Article 23 notification obligations as a major national agency, provided its activities fall within the Directive’s scope.

The scope boundary is not a simple binary. Article 2 draws three overlapping lines:

Article 2(7) — Full exclusion: The Directive “does not apply to public administration entities that carry out their activities in the areas of national security, public security, defence or law enforcement, including the prevention, investigation, detection and prosecution of criminal offences.” A domestic intelligence agency or border police force is excluded in full.

Article 2(8) — Optional member-state exemption: Even where a public body is partly in scope, member states may choose to exempt specific entities from Article 21 (security measures) or Article 23 (incident reporting) — or both — for the activities listed in paragraph 7. Where an entity carries out those activities or provides services exclusively to Art. 2(7)-excluded bodies, member states may also exempt it from the registration and registration obligations in Articles 3 and 27.

Article 2(9) — Trust service provider override: Paragraphs 7 and 8 “shall not apply where an entity acts as a trust service provider.” A government body issuing qualified certificates or time-stamps under eIDAS cannot claim the national security exclusion for its trust service activities, regardless of how the rest of its mandate is classified.

The table below maps common public administration entity types to their likely NIS2 scope status. Member-state transposition determines the definitive answer — treat this as a framework for initial classification, not a legal determination.

Entity type	NIS2 scope status	Governing provision
Central government ministry or agency — civil mandate only	Essential entity; full Art. 21 and Art. 23 obligations apply	Annex I sector 10; Art. 2(2)(f)
Central government body with mixed civil and security functions	Partial — Art. 2(7) excludes security activities; civil IT systems remain in scope unless Art. 2(8) exemption applied by the member state	Art. 2(7)–(8)
Intelligence service or domestic security agency	Excluded — Art. 2(7) full exclusion applies	Art. 2(7)
Military or defence force	Excluded — Art. 2(7) full exclusion applies	Art. 2(7)
Regional government body (e.g. Länder, province, region)	In scope only if the member state has extended NIS2 to regional level under Art. 2(5)(a)	Art. 2(5)(a)
Government trust service provider (qualified certificates, time-stamps)	In scope for trust service activities — Art. 2(9) bars the exclusion claim regardless of other mandates	Art. 2(9)
Entity providing services exclusively to Art. 2(7)-excluded bodies	Member state may apply Art. 2(8) exemption for those services	Art. 2(8)

The Art. 2(7) Classification Dilemma: Government IT Incident or National Security Incident?

The operational problem most public sector CISOs encounter is not deciding whether they are in scope — it is deciding, under time pressure during an active incident, whether a specific event triggers NIS2 notification or national security escalation instead.

Consider a ransomware attack that encrypts the email infrastructure of a ministry of internal affairs. That ministry is largely a civil body in scope under NIS2 Annex I sector 10. But the attack also compromised a file share used partly by the ministry’s internal security unit. Does Article 23’s 24-hour clock start — or does the ministry escalate through national security channels?

NIS2 provides no incident-level classification test. Article 2(7) is an entity-level exclusion, not an event-level one. Where a public body’s activities are “only marginally related” to national security functions, it remains in scope — meaning the body must apply a judgment call to each incident. Four factors guide that judgment:

• Affected systems: Did the incident impact IT systems that exclusively serve a national security function? If yes, Art. 2(7) logic may apply to that subset. If civil-service systems were affected, NIS2 applies to that scope regardless.
• Operational impact on public services: Did the incident disrupt civil services — citizen portals, benefit systems, registry services? Disruption to these triggers NIS2 Art. 23 notification independently of any security-unit involvement.
• Classified information exposure: Were classified materials accessed or exfiltrated? If yes, national security escalation procedures typically take precedence. Contact your national competent authority immediately to determine whether Art. 23 reporting is suspended pending classification.
• Cross-border risk: Does the incident have implications for other member states’ essential services? Cross-border incidents amplify the NIS2 notification obligation under Article 23 and trigger ENISA and single-point-of-contact coordination.

In practice, the default position should be to file the Art. 23 early warning within 24 hours while simultaneously notifying the national competent authority of the classification uncertainty. The cost of over-reporting to the CSIRT is low — notification itself creates no increased liability under Art. 23. The cost of under-reporting — missing the 24-hour window — is a potential enforcement action under Article 32 or 33. Formal reclassification as a national security incident can be coordinated with your member state’s NCA after the initial warning is filed.

Art. 23’s Three-Stage Notification Timeline for Public Bodies

In-scope public administration bodies follow the same Art. 23 notification structure as any essential entity — but specific features of government IT environments (long procurement cycles, shared infrastructure, coalition-style IT governance) create gaps that a standard incident response plan does not address.

Article 23(4) requires three distinct submissions after a significant incident. For more detail on the Article 23 notification framework in general, that dedicated page covers the full technical requirements; what follows focuses on the public-sector-specific considerations within each stage.

Stage 1 — Early warning (within 24 hours of becoming aware): The submission must indicate whether the incident is suspected to be caused by unlawful or malicious acts and whether it has cross-border impact potential. For government bodies, “becoming aware” starts the clock — not when the full scope of the incident is understood. If your SOC flags a major anomaly at 03:00, the 24-hour window begins then, not when the morning shift reviews the alert. The early warning does not require a complete technical picture; it requires an honest snapshot of what is known at the time of submission.

Stage 2 — Incident notification (within 72 hours): This submission must include an initial assessment of severity and impact, indicators of compromise, and where possible the cause. Government systems often run shared infrastructure across departments on legacy contracts that predate modern incident visibility tooling. The 72-hour notification must reflect the full scope of affected systems as understood at that point — if the incident has propagated across departments, all affected services must be listed, not only the initially identified system.

Stage 3 — Final report (within one month of the Art. 23(4) submission): The final report requires a detailed description of the incident, its root cause, mitigation measures taken, and cross-border implications. For public bodies, this report forms part of the supervisory audit trail under Article 32. Treat it as a document that a competent authority inspector will read alongside your incident log, corrective actions register, and board briefing — not as an internal post-mortem.

An incident is “significant” under Art. 23(3) if it causes severe disruption to service delivery, financial loss, or material or immaterial damage to service users. A multi-hour outage of a citizen-facing tax filing portal crosses the threshold; a transient network blip that self-corrected within minutes does not. Maintain an incident classification matrix in your incident log that documents why each event was or was not assessed as significant — this is the first document an inspector will request.

Government trust service providers face a stricter regime: Article 23(4) gives trust service providers a 24-hour window for all significant incidents affecting trust services, with no 72-hour intermediate notification. A government-operated certification authority or time-stamping service must notify its CSIRT within 24 hours of becoming aware — the standard three-stage sequence does not apply to this sub-category. For the full incident reporting workflow including trigger criteria and escalation paths, see the dedicated guidance.

GovCERT vs. National CSIRT — Country Routing Table for Central Government

Routing your Art. 23 notification to the wrong authority is not a technicality — it is non-compliance. Most member states operate at least two CSIRT-type bodies: one for government entities and one for the private sector, with separate reporting portals, separate contacts, and separate escalation chains.

The logic for separate public-sector channels is operational: government IT incident reports require sovereign-channel protection. A notification from a ministry of justice should not transit the same channels as a report from a commercial telecoms operator. Public sector CSIRTs are typically hosted within government structures, staffed with personnel holding security clearances, and operationally connected to national crisis coordination mechanisms that have no private-sector equivalent.

The table below provides the routing structure for three key member states. National transposition creates significant variation across the EU. Confirm your definitive routing with your national competent authority’s implementation guidance before writing it into your incident response plan.

Country	Public sector CSIRT / channel	Reporting contact	Private-sector CSIRT	Implementation notes
Germany (DE)	BSI (Bundesamt für Sicherheit in der Informationstechnik) — GovCERT function integrated within BSI; federal authorities (Bundesbehörden) use separately defined reporting channels	Federal agencies: existing established channels, not the public BSI incident portal (launched January 2026)	BSI Portal (launched January 6, 2026) for private-sector NIS2 entities	BSIG 2025 in force December 6, 2025; private-sector entities register via Mein Unternehmenskonto (MUK); Bundesbehörden procedures governed by separate federal IT security provisions
Austria (AT)	GovCERT Austria — Government CERT hosted at the Federal Chancellery (Bundeskanzleramt)	NIS portal: nis.govcert.gv.at | Incident email: reports@govcert.gv.at	CERT.at (operated by CERT.at GmbH, subsidiary of nic.at) — all non-government entities	Clear operational split: public administration → GovCERT; all other entities → CERT.at. Austria’s NIS2 transposition (NISG 2026) pending as of mid-2026; current NISG obligations remain applicable
Netherlands (NL)	NCSC-NL (Nationaal Cyber Security Centrum) — serves both central government and vital-sector operators under the Wbni	Mandatory reporting portal: mijn.ncsc.nl (monitored 24/7)	Sector-specific authorities for entities outside central government and vital sectors; Cyberbeveiligingswet (NIS2 implementation) expected July 2026	NCSC-NL is unique among the three: it is the single mandatory reporting authority for both central government and vital sectors, not a split model. Cyberbeveiligingswet will expand NCSC mandate further

The Netherlands model differs structurally from Austria and Germany: NCSC-NL functions as a single mandatory CSIRT for both central government bodies and vital-sector operators. Austria and Germany route government and private sector to entirely separate CSIRT bodies. Understanding which model your member state follows is the foundational step in building a compliant incident response plan.

For member states not listed above, locate your national competent authority’s implementation guidance at the ENISA national authority directory. The Art. 23(1) obligation requires notification to “its CSIRT or, where applicable, its competent authority” — the “or, where applicable” clause means some member states route primary reporting to the competent authority directly, with the CSIRT receiving a copy. Confirm which pathway your member state has designated before an incident occurs.

Audit-Ready Documentation: What Your Art. 23 Notification Must Contain

Filing an Art. 23 notification is not the end of the compliance obligation — it is the beginning of the audit trail. What you submit, when you submit it, and what you can demonstrate to a competent authority inspector six months later are three separate requirements that a poorly constructed incident response process conflates into one.

Each of the three notification stages has specific mandatory content under Art. 23(4). The table below maps those requirements to the internal documentation that supports an audit-ready submission:

Notification stage	Mandatory content (Art. 23(4))	Supporting internal document	Common public sector gap
24h early warning	Nature of incident; is it suspected to be malicious? Cross-border impact potential?	Incident log entry timestamped from time of awareness; CSIRT/NCA confirmation receipt	No timestamp discipline — teams log the “discovery date” as the incident date rather than the precise time of awareness, making the 24-hour clock impossible to reconstruct in an audit
72h notification	Initial severity and impact assessment; indicators of compromise (IoCs); affected systems; estimated user impact	Incident notification form pre-populated for each service type; IoC register; affected-systems inventory	Shared infrastructure listed ambiguously — affected systems described only for the initially visible impact point, without listing downstream dependent services that were also disrupted
1-month final report	Root cause; mitigation measures; cross-border impact; threat type	Post-incident review report; corrective actions register with owners and remediation deadlines	Report authored by IT team in isolation — no legal review, no board acknowledgement, not treated as a regulatory submission requiring sign-off

Role ownership for Art. 23 compliance in a public administration body involves four functions that must be explicitly assigned before an incident occurs:

• CISO / IT Security Manager: Detects, classifies, and authors the technical content of all three submissions. Owns the incident classification matrix, the IoC register, and the affected-systems inventory. Initiates the 24-hour early warning clock from the moment of awareness.
• Legal / Data Protection Officer: Reviews all three submissions before filing. Confirms the scope classification decision (NIS2 vs. national security). Ensures consistency with any parallel GDPR notification — the GDPR 72-hour personal data breach deadline runs simultaneously for incidents involving personal data, to a different authority.
• Chief Information Officer / CTO: Authorises the 72-hour notification and the final report. Owns the statement of affected systems and the service continuity impact assessment.
• Management body / Board: Receives the final report under Art. 20(1) governance obligations. Article 20(1) requires management bodies to approve cybersecurity risk management measures and creates accountability for infringements. The Art. 23 notification process and forms should be within the scope of that formal approval — meaning the board must have seen and approved the templates before the incident.

Penalties, Enforcement, and Supervisory Oversight for Public Administration Bodies

The NIS2 financial penalty maxima — €10 million or 2% of worldwide annual turnover for essential entities, €7 million or 1.4% for important — are widely cited. Less discussed is how they apply to public administration bodies, where the Directive leaves significant discretion to member states.

Article 32 grants competent authorities proactive supervisory powers over essential entities: on-site inspections, off-site supervision, security audits, and requests for documentation without prior notice. Article 33 applies a lighter reactive regime to important entities. Both provisions apply to in-scope public administration bodies regardless of whether financial penalties follow. A government body that misses the 72-hour notification window can expect a supervisory inquiry and a request for the incident log, classification rationale, and submission records — irrespective of its member state’s stance on fines.

The financial penalty picture is more complex. NIS2 sets maximum figures but does not mandate that member states apply those figures to public bodies. Several member states explicitly limit enforcement for government entities to corrective orders and binding directions, without financial fines. Latvia’s national cybersecurity law provides a documented example: it applies a graduated private-sector enforcement chain (warning → binding direction → daily penalty → fine), but caps public sector enforcement at corrective orders and public disclosure, with no financial fines for government bodies.

The questions to confirm with your legal team are:

1. Has your member state applied financial penalties to public administration bodies under its NIS2 transposition, or limited enforcement to corrective measures?
2. Has your member state exercised the Art. 2(8) optional exemption from Art. 23 for any of your entity’s activities — and if so, for which activities specifically?
3. Does your member state’s transposition hold individual management members personally liable under governance provisions equivalent to Art. 20?

On the third point: Article 20(1) applies to management bodies of in-scope public administration bodies. A government agency that correctly files an Art. 23 notification but cannot demonstrate that its board formally approved the underlying incident response framework remains exposed to an Art. 20 governance enforcement action — independently of the Art. 23 filing itself. The governance obligation and the notification obligation are enforced separately.

Action Checklist for In-Scope Public Administration Bodies

Six steps that should be completed before an incident occurs — not during one:

1. Document your Art. 2(7) classification. Determine formally whether your entity’s activities place it within or outside the national security exclusion. Record the classification rationale, the functions assessed, and the date of assessment. Review it whenever your entity’s mandate changes.
2. Confirm your member state’s GovCERT routing. Identify the correct government CSIRT and reporting channel for your jurisdiction — do not assume the private-sector CSIRT channel applies. Test the channel with your SOC team and document the confirmation.
3. Verify the Art. 2(8) status. Confirm with legal counsel whether your member state has applied the optional exemption from Art. 21 or Art. 23 for any of your entity’s activities, and for which activities specifically.
4. Build timestamp discipline into your incident log. The 24-hour clock starts at “time of awareness,” not “time of full technical understanding.” Pre-configure your incident log to capture the awareness timestamp automatically on first entry.
5. Obtain board approval of your Art. 23 forms. Under Art. 20(1), management bodies must approve cybersecurity risk management measures. Ensure the Art. 23 notification templates and classification matrix have formal board sign-off before an incident occurs.
6. Run an annual routing test. At least once per year, send a test notification through your designated GovCERT reporting channel and confirm receipt. CSIRT contacts and portals change — the time to discover a broken channel is not at 03:00 during an active incident.

Frequently Asked Questions

Does a regional government body need to comply with NIS2 Article 23?

Only if the member state has extended NIS2 scope to regional level under Article 2(5)(a). Central government bodies are in scope automatically under Annex I sector 10. Regional inclusion is optional and must be specified in the national transposition law — check your member state’s implementing legislation.

What happens if an in-scope public body files the Art. 23 notification to the wrong authority — for example, the private-sector CSIRT instead of GovCERT?

There is no grace clause in the Directive for misdirected notifications. A report filed to the wrong authority does not satisfy the Art. 23(1) obligation. Establish the correct reporting channel for your member state before an incident occurs, and test it with your SOC team at least annually.

If a public body is excluded under Art. 2(7), does it have any cybersecurity notification obligations at all?

Not under NIS2. However, most member states impose equivalent or stricter notification obligations on national security bodies through separate national security or intelligence legislation. Exclusion from NIS2 does not mean exclusion from all reporting requirements — it means the NIS2 framework does not govern those requirements.

Can an Art. 23 notification be reclassified as a national security matter after it has been filed?

Yes. The national competent authority can coordinate with the government body to restrict or reclassify information after the initial filing. The operationally correct approach is to file the 24-hour early warning first and coordinate reclassification with the NCA in parallel. Delaying the early warning pending classification creates greater enforcement exposure than filing and then managing classification with the authority.

Legal Disclaimer

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. “Article 23: Reporting Obligations” — NIS 2 Directive. nis-2-directive.com
2. “Article 2: Scope” — NIS 2 Directive. nis-2-directive.com/NIS_2_Directive_Article_2.html
3. “NIS Reports” — GovCERT Austria. govcert.gv.at/en/reporting-incidents/nis-reports.html
4. “GovCERT Austria” — Federal Chancellery of Austria. govcert.gv.at/en/
5. “Report an incident to NCSC-NL” — NCSC-NL. ncsc.nl/en/report-an-incident-to-ncsc-nl
6. “Statutory Mandate” — NCSC-NL. ncsc.nl/en/about-us/statutory-mandate
7. “NIS 2 Directive Transposed in Germany” — DLA Piper (February 2026). dlapiper.com