Government Shared Services Under NIS2: Why NHS-Style IT Suppliers Create Article 21(2)(d) Risks Most Entities Miss

When one provider processes payroll and financial transactions for dozens of public sector bodies simultaneously, a single security failure at that provider does not create one incident — it creates dozens. Every entity sharing the platform may independently trigger its own Article 23 notification obligation to its national competent authority. That is not a hypothetical. It is the structural reality of shared government IT, and it is the supply chain risk that most NIS2 compliance programmes in the public sector have not yet documented.

Central government bodies are automatic essential entities under Article 3(1)(d) of Directive 2022/2555. They inherit the full weight of Article 21’s ten security measures, including Article 21(2)(d), which requires documented supply chain security covering direct suppliers and service providers. [1][3] The directive does not define “direct supplier” to exclude government-owned platforms, shared services mandated by central government efficiency programmes, or cloud providers used across an entire ministry portfolio.

Most NIS2 supply chain guides focus on commercial entities and their ICT vendors. None address the specific problem facing public administration: shared services that are mandatory, embedded into multiple essential entity operations simultaneously, and often operating under contracts that pre-date NIS2 by years. This article closes that gap.

It covers why central government entities cannot reduce their Article 21(2)(d) obligations, how government shared services create single-point-of-failure risk, what the directive actually requires you to document for each supplier, and how to build an assessment framework that reflects the specific constraints of public sector procurement.

Why Central Government Cannot Opt Out of NIS2 Supply Chain Obligations

Unlike private-sector entities, which must pass a size threshold before NIS2 designates them as essential entities, central government bodies face a different rule entirely. Article 2(2)(f)(i) of Directive 2022/2555 covers public administration entities at central government level “regardless of size.” A 15-person government digital unit carries identical NIS2 obligations to a ministry with 20,000 staff. [2]

Article 3(1)(d) then classifies all such entities as essential entities automatically, triggering the maximum tier of obligations: proactive supervision by competent authorities, 24-hour early-warning incident notification under Article 23, and the complete set of Article 21 risk management measures. [3] The directive’s proportionality language gives essential entities some flexibility in how they implement controls, but the baseline it sets is high. Regional government bodies fall under Article 2(2)(f)(ii) only where disruption of their services would have a significant impact on critical societal or economic activities — subject to a member state risk assessment. Local government bodies remain optional for member states under Article 2(5)(a). [2]

Entity type	NIS2 article	In scope?	Entity class
Central government ministry or agency	Article 2(2)(f)(i)	Yes — regardless of size	Essential
Regional government body	Article 2(2)(f)(ii)	Only if disruption would significantly impact critical activities	Essential (if designated)
Local government body	Article 2(5)(a)	Member state discretion	Essential (if designated)
Government-owned IT shared service (large)	Article 6(39) — MSP definition	Likely — if 250+ employees or €50M+ turnover	Essential or Important (own-account)
Government-owned IT shared service (medium)	Article 6(39) + Annex II	Likely as Important entity	Important (own-account)

The scope decision has a practical supply chain consequence that is frequently missed. A government-owned shared IT service provider — such as NHS Shared Business Services in England or Germany’s federal government IT infrastructure platforms — may be a NIS2-regulated entity in its own right under the managed service provider definition in Article 6(39). [4] But that does not discharge the assessment obligation of the government bodies using it. Each essential entity is independently required to assess its direct suppliers under Article 21(2)(d), including those it has no commercial choice but to use. [1] To understand how entity classification works across your supply chain, see our essential vs important entity guide.

Government Shared Services as Single Points of Failure Under Article 21(2)(d)

The EU’s own cybersecurity agency has identified the structural risk here explicitly. ENISA’s Threat Landscape 2025 flags “cross-border ICT service providers as a single point of failure” as one of the top ten emerging cybersecurity threats through 2030, and documents that compromising one managed service provider gives attackers access to dozens of downstream customers — what ENISA describes as the most concerning trend in supply chain initial access vectors. [5][6] Public administration is the most targeted sector in the EU, accounting for the largest share of incidents in ENISA’s 2025 analysis across 4,875 incidents monitored from July 2024 to June 2025. [5]

Government shared services amplify this risk beyond typical commercial managed services for three structural reasons.

Scope breadth. A single shared IT service often covers payroll, accounts payable, HR systems, and enterprise resource planning across dozens of central government departments simultaneously. NHS Shared Business Services, for example, processes financial and transactional services for NHS organisations across England. A security incident affecting NHS SBS is not a single essential entity incident — it is a multi-entity incident affecting every organisation sharing the platform, each with its own Article 23 notification clock. For a full breakdown of notification timelines, see our Article 23 incident notification guide.

Mandatory use. Unlike commercial entities that can diversify suppliers in response to a risk assessment, many government bodies use shared services because they are mandated by central government efficiency programmes or procurement frameworks. The supplier is not selected on competitive grounds after a NIS2 risk assessment — it is assigned. Article 21(2)(d) still requires the assessment to happen regardless of whether the entity had a choice. Risk acceptance documentation for mandated suppliers is the correct output, not a supplier switch.

Fourth-party exposure. ENISA has documented what it terms “fourth-party blast-radius dynamics” — where neither end-customers nor direct suppliers had visibility into upstream security failures that cascaded into operational disruption. [6] In a government shared services context, a ministry may have documented its direct supplier (the shared IT service) but have no visibility into the shared service’s own ICT sub-contractors. Article 21(3) requires entities to integrate the findings of coordinated security risk assessments of critical supply chains carried out under Article 22(1) — precisely because individual entities cannot independently map fourth-party risk. [1]

Cloud-First Government Strategy and the Annex I Supplier Problem

European governments have pursued cloud-first digital transformation strategies throughout the 2020s, concentrating workloads onto a small number of hyperscale providers. The result is structural: US-based cloud providers now control more than 70% of the European cloud market, and government systems — from tax administration platforms to benefits processing to inter-agency communications infrastructure — run on shared infrastructure controlled by a handful of providers. [7]

The October 2025 AWS global outage illustrated what this concentration means at scale. When AWS experienced a global failure, banks, hospitals, airlines, and government systems slowed or halted simultaneously — not because each had individually failed, but because each shared a common infrastructure dependency. [7] The CrowdStrike incident of July 2024 demonstrated the same dynamic from a different vector: a faulty software update in one supplier grounded operations across multiple sectors globally. [7] Government entities sitting inside this cloud infrastructure inherited the outage without having sourced, configured, or triggered it.

Under NIS2, cloud computing service providers are regulated entities in their own right. Article 21(5) directed the European Commission to adopt implementing acts specifying technical and methodological requirements for cloud computing service providers, DNS providers, data centre operators, and content delivery networks. [1] The Commission’s implementing regulation CIR 2024/2690, adopted in November 2024, sets binding security requirements for these providers. This creates a layered compliance picture that government entities need to map explicitly:

Layer	NIS2 status	Your obligation as customer
Cloud hyperscaler (AWS, Azure, GCP)	NIS2 essential/important entity; subject to CIR 2024/2690	Article 21(2)(d) assessment + contractual security clauses
Government shared IT service (MSP)	Likely NIS2-regulated under Article 6(39) MSP definition	Article 21(2)(d) assessment + Article 21(3) vulnerability review + contractual clauses
Your central government entity	NIS2 essential entity, Article 3(1)(d)	Full Article 21 implementation + Article 20 management approval + Article 23 incident notification

The critical point: a supplier’s own NIS2 regulatory status does not discharge your entity’s Article 21(2)(d) obligation toward it. Article 21(3) requires you to evaluate “the overall quality of products and cybersecurity practices of your suppliers and service providers” — which is a documented due diligence requirement, not a pass-through granted by the supplier’s certification or regulatory filing. [1] A cloud provider’s CIR 2024/2690 compliance is evidence relevant to your assessment; it does not replace the assessment.

What Article 21(2)(d) Actually Requires Government Entities to Document

Article 21(2)(d) requires “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” Article 21(3) then specifies that entities must consider “the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures,” as well as “the results of the coordinated security risk assessments of critical supply chains carried out in accordance with Article 22(1).” [1]

Several aspects of this requirement are routinely misread in government compliance programmes.

“Direct” does not mean “primary” or “commercially negotiated.” The directive uses “direct supplier” to mean any supplier that delivers a service directly to your organisation, including mandated shared services and government-assigned platforms. The commercial nature of the relationship, or the absence of a negotiated contract, does not change the assessment obligation. For guidance on how to classify suppliers by criticality, see our article on how to classify NIS2 suppliers.

The assessment must be supplier-specific. A single template security questionnaire distributed to all suppliers simultaneously does not satisfy Article 21(3)’s requirement to consider vulnerabilities “specific to each direct supplier.” ENISA’s supply chain guidance makes clear that entity-level evaluation — covering the supplier’s secure development procedures, incident history, sub-contractor concentration, and specific exposure to your data — is expected. [5] In a government shared services context, this means separately documenting the risk posed by NHS SBS to your entity’s specific data, your entity’s specific operational continuity, and your entity’s specific notification exposure — not a shared document produced once for all member organisations of the platform.

Contractual clauses are necessary but not sufficient. Law firm analysis of the directive notes that most government IT contracts will require amendment to include NIS2-compliant incident notification obligations, audit rights, and sub-contractor visibility provisions. [8] But the contract clause evidences the requirement; it does not constitute the risk assessment. Both are required.

Government-to-government shared services require assessment. The directive text contains no exemption for suppliers that are themselves public sector bodies. If your ministry uses a centrally mandated shared service — even one wholly owned by the same government — Article 21(2)(d) requires you to assess it. The essential entity designation creates the obligation; the ownership structure of the supplier does not remove it.

Document required	Content	Frequency
Supplier criticality classification	Tier (critical / important / standard) based on impact if supplier fails or is compromised	Annual or on material change
Supplier-specific vulnerability assessment	Concentration exposure (how many other entities share the platform), sub-contractor chains, incident history, secure development practices	Annual or on material change
Supplier security questionnaire	Supplier’s own NIS2 compliance status, incident notification timeline, audit rights, key-person dependencies	Annual
Contractual security clauses	NIS2 incident notification obligations, sub-contractor visibility, audit rights	On contract renewal or at next available opportunity
Risk acceptance record (mandated suppliers)	Documented risk decision, concentration exposure, compensating controls in place	Annual or on renewal of mandate
Article 22 coordinated assessment inputs	Findings from ENISA or NCA-coordinated sector-level supply chain risk assessments, integrated into individual supplier record	When published by competent authority

The full supply chain documentation obligation is covered in detail in our guide to supply chain security under NIS2.

Building a Supplier Assessment Framework for Public Administration

A government-specific NIS2 supplier assessment framework needs to handle three scenarios that standard corporate supplier management processes are not designed for. Each requires a different output, but all three require documentation.

Scenario 1 — Mandated shared services. Your entity has no commercial choice in supplier. The assessment still happens, but the output is a risk acceptance record rather than a sourcing decision. Document the shared service’s specific vulnerabilities, the concentration exposure (how many other government bodies share the platform), and any compensating controls your entity can deploy: additional monitoring, data-access segmentation, local failover for critical functions, independent backup. The risk acceptance record, approved by the management body under Article 20, is the evidence of due diligence when you cannot change the supplier. [10]

Scenario 2 — Consortium procurement. Multiple departments procure through a central framework or cross-government agreement. Article 21(2)(d) obligations can be partially pooled — one entity performs the initial supplier assessment and shares the output with other departments — but each entity remains responsible for verifying that the shared assessment covers its specific use case and its specific vulnerability exposure. A shared assessment is a starting point, not a complete discharge of the individual entity’s obligation.

Scenario 3 — Legacy contracts pre-dating NIS2. Many government IT contracts were signed before October 2024 and contain no NIS2 security provisions, incident notification obligations, or audit rights clauses. The directive does not create automatic retroactive amendment. Your entity must renegotiate at the next contract renewal. In the meantime, document the gap, assess the residual risk under the existing contract terms, and record what compensating controls are in place while renegotiation is pending. [8]

Role	Owns	Supports
CISO / IT Security	Supplier vulnerability assessment; technical control mapping for each shared service	Compliance Officer
Procurement / Commercial	Contractual security clause insertion; sub-contractor visibility tracking	Legal
Compliance Officer	NIS2 supplier register; documentation completeness; integration of Article 22 coordinated assessment outputs	CISO
Board / Senior Management	Risk acceptance sign-off for mandated suppliers; Article 20 governance approval record	Compliance Officer
Legal	Contract amendment strategy for pre-NIS2 agreements; sub-contractor visibility clause drafting	Procurement

For a full walkthrough of the public administration NIS2 scope and compliance obligations specific to government bodies, see our dedicated public administration NIS2 guide.

Enforcement, Penalties, and What NIS2 Means for Government Bodies

NIS2 sets the maximum fine for essential entities at €10 million or 2% of total global annual turnover, whichever is higher. [9] As of May 2026, 21 of 27 EU member states have transposed NIS2 into national law, and competent authorities across the EU are actively deploying supervisory mechanisms against essential entities — with central government bodies sitting at the top of the priority list given their automatic essential entity designation. [9]

Beyond fines, Article 21 enforcement empowers competent authorities to issue binding compliance instructions with specific deadlines, order security audits at the entity’s expense, suspend certifications or authorisations relevant to the entity’s functions, and — for repeated or serious violations — recommend that management be temporarily banned from their positions. The financial penalty for government bodies varies by member state: some jurisdictions limit public sector financial exposure, but the board accountability provisions are not similarly capped.

Article 20 requires management bodies to approve cybersecurity risk management measures and oversee their implementation; management members can be held liable for infringements, without prejudice to national law regarding public institutions and public servants. [10] This creates a compliance picture that matters beyond the supply chain register itself: the supplier vulnerability assessment documented under Article 21(2)(d) is simultaneously evidence of Article 20 governance compliance. A management body that has formally approved the supplier risk register — including the risk acceptance records for mandated shared services — has a documented governance trail that reduces personal liability exposure under Article 20. One without it does not. For the full board accountability picture, see our guide on board directors and NIS2 liability.

Frequently Asked Questions

Does NIS2 apply to a small central government digital agency with fewer than 50 employees?

Yes. Article 2(2)(f)(i) explicitly removes the standard size threshold for central government public administration entities. Any ministry, agency, or central government body falls within NIS2 scope regardless of headcount or annual turnover. [2]

If our shared IT service provider is itself NIS2-compliant, does that discharge our Article 21(2)(d) obligation?

No. A supplier’s own NIS2 compliance is relevant evidence for your assessment, but it does not replace the assessment. Article 21(3) requires you to evaluate vulnerabilities specific to your entity’s use of the supplier, including the concentration exposure from other entities sharing the same platform. [1] Your supplier’s regulatory filing is not your due diligence record.

Do we need to assess shared services that are other public sector bodies?

Yes. The directive text contains no exemption for suppliers that are public sector bodies or government-owned entities. If a government shared service provides a service within your NIS2 operational perimeter, it requires assessment under Article 21(2)(d) regardless of its ownership structure. [1]

What is the Article 22 coordinated risk assessment, and does it replace our own supplier assessment?

Article 22(1) allows the Cooperation Group to conduct coordinated risk assessments of critical supply chains at EU level. Article 21(3) requires entities to integrate the findings of those assessments into their own supplier reviews when published. [1] The coordinated assessment supplements your obligation; it does not replace the entity-specific supplier vulnerability documentation Article 21(3) requires.

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.

Key Takeaways

Government shared services are not a niche edge case in NIS2 supply chain compliance — they are the dominant IT delivery model in European public administration, and Article 21(2)(d) treats every entity using them as having a direct supplier relationship that requires individual assessment. The mandatory nature of the shared service, the government ownership of the provider, or the absence of a negotiated contract does not remove that obligation.

The assessment framework for public administration entities needs to handle three specific scenarios that standard corporate supplier management is not built for: mandated shared services (risk acceptance output), consortium procurement (shared-but-not-discharged obligation), and legacy pre-NIS2 contracts (gap documentation plus compensating controls). All three require documentation; none allow the obligation to be deferred to the supplier’s own compliance filing.

For entities building their NIS2 programme, the supplier register is the correct starting point — because it is simultaneously the Article 21(2)(d) supply chain documentation, the Article 20 management approval evidence, and the audit trail that competent authorities will examine first.

Sources

• [1] Article 21 — Cybersecurity Risk-Management Measures, Directive (EU) 2022/2555
• [2] Article 2 — Scope, Directive (EU) 2022/2555
• [3] Article 3 — Essential and Important Entities, Directive (EU) 2022/2555
• [4] Article 6 — Definitions (Managed Service Provider, Cloud Computing Service), Directive (EU) 2022/2555
• [5] ENISA Threat Landscape 2025, European Union Agency for Cybersecurity
• [6] ENISA Threat Landscape 2025 — Supply Chain Findings, safeguard.sh
• [7] Cloud tech outages: how the EU plans to bolster its digital infrastructure, The Conversation
• [8] NIS2 directive explained Part 3: Supply chain security, DLA Piper
• [9] NIS2 enforcement 2026: critical infrastructure, government, and defence can’t wait, 6clicks
• [10] Article 20 — Governance, Directive (EU) 2022/2555