NIS2 Art.22: EU-Level Coordinated Security Risk Assessment of Critical Supply Chains — What SaaS Developers Need to Know (2026)

Post #416 in the sota.io EU Cyber Compliance Series

Most NIS2 compliance guides focus on what your organisation must do: implement security measures under Art.21, report incidents under Art.23, disclose vulnerabilities under Art.26. Art.22 operates at a different level entirely — it is the mechanism by which the EU collectively identifies which supply chains pose systemic risk to European critical infrastructure, and mandates coordinated action before incidents occur.

For SaaS developers, Art.22 matters in two ways. First, if your product is part of a supply chain that gets assessed (cloud hosting, DNS, authentication libraries, container runtimes), the assessment conclusions may directly tighten the security requirements your customers impose on you. Second, if you are an essential or important entity, the national implementation of Art.22 recommendations defines the minimum bar you must meet for third-party risk management under Art.21.

This guide covers:

• Art.22 text and structure — what it actually requires from whom
• The 5G Toolbox precedent — how coordinated supply chain risk assessment has worked in practice
• Which supply chains are in scope for EU-level assessment
• How assessments work: Cooperation Group + ENISA → report → Commission recommendations → NCA implementation
• How Art.22 recommendations flow down to affect your Art.21 obligations
• Python SupplyChainRiskMonitor — track assessment outputs and map to your vendor stack
• Art.22 vs Art.21(2)(d): macro-level vs entity-level supply chain risk
• NIS2 × DORA × CRA cross-map
• 20-item compliance checklist

NIS2 Art.22 in Context

Art.22 sits within NIS2 Chapter III, which governs EU-level cybersecurity coordination. Unlike Chapter IV (entity obligations) or Chapter VI (competent authorities), Chapter III deals with collective EU actions — the Cooperation Group, ENISA, and the Computer Security Incident Response Teams (CSIRTs) Network working together on systemic risks.

The Chapter III framework:

Important nuance: NIS2 renumbered several articles between the Commission proposal and the final text. What appears as Art.22 in the final Directive (EU) 2022/2555 is the coordinated supply chain security risk assessment provision. Always verify against the official OJ text when referencing specific paragraph numbers.

What Art.22 Actually Requires

Art.22 NIS2 has two operative paragraphs:

Art.22(1) — Mandate to assess: The Cooperation Group, in cooperation with the Commission and ENISA, shall conduct coordinated security risk assessments of specific critical ICT services, systems, or products supply chains, taking into account technical and non-technical risk factors.

The assessment shall also take into account measures, mitigating factors, and good practices including on supply chain security.

Art.22(2) — Commission recommendations: On the basis of the assessment under paragraph 1, and having regard to the results, the Commission may adopt implementing acts recommending that essential and important entities assess the cybersecurity risks of specific critical supply chains and, where appropriate, integrate the results of such assessment into their risk management measures under Art.21.

What this creates in practice:

The mechanism is: Assessment → Report → Commission Implementing Act → NCA enforcement → Entity Art.21 update

Member States cannot ignore Commission implementing acts based on Art.22 assessments — they must transpose the recommendations into national guidance or requirements for entities in scope.

The 5G Toolbox: Proof the Mechanism Works

Art.22 was written with the 5G supply chain assessment explicitly in mind. Before NIS2, the EU used a similar coordinated mechanism to assess risks in 5G networks — the process that produced the "EU 5G Toolbox" in January 2020.

How the 5G assessment worked:

1. National risk assessment (2019): Each Member State assessed its 5G network risks independently, identifying threat actors, attack surfaces, and infrastructure dependencies.

2. EU coordinated risk assessment: ENISA synthesised national reports into a Union-level risk profile, identifying cross-border systemic risks that no single Member State could see alone. Key finding: concentration risk from a small number of suppliers creates a single point of failure for EU-wide 5G.

3. Toolbox: The Cooperation Group published risk categories (high-risk suppliers, medium-risk components) and mitigation measures (technical measures TM01–TM09, strategic measures SM01–SM07).

4. National implementation: Member States were expected to implement toolbox measures through national regulatory instruments. Germany's § 9(5) TKG supplier requirements, France's ANSSI supplier authorisation scheme, and Sweden's PTS restrictions all flowed from the toolbox.

5. Procurement impact: Mobile operators were required to evaluate suppliers against the toolbox risk categories. Huawei's market position in EU 5G networks shifted materially as a result.

The 5G Toolbox demonstrates the Art.22 mechanism is not theoretical — it produces binding practical guidance with real market effects.

For SaaS developers: The same mechanism now applies to the supply chains you depend on: cloud providers, DNS resolvers, authentication SDKs, container runtimes, open-source libraries with widespread adoption.

Which Supply Chains Are in Scope for Art.22 Assessment

Art.22 does not enumerate specific supply chains — the Cooperation Group selects targets through its annual work programme based on strategic importance and risk concentration. However, the Cooperation Group has published guidance on supply chain security (SCS guidelines, ENISA supply chain security reports) that signals priorities:

High-Priority Supply Chain Categories

1. Cloud infrastructure and managed services

• IaaS/PaaS/SaaS providers serving critical sectors
• CDN providers (concentration: 3-4 providers serve >80% of EU traffic)
• Managed security service providers (MSSPs)

Why prioritised: The NIS2 recitals explicitly note that cloud services present systemic risk due to provider concentration. Art.6(35) NIS2 defines "cloud computing service" as a category of digital infrastructure — entities operating these are subject to Chapter IV obligations.

2. Domain Name System (DNS) infrastructure

• DNS resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1 — US-operated, used by EU entities)
• TLD registries and registrars
• DNSSEC infrastructure

Why prioritised: DNS is the internet's addressing system. A successful attack on a major resolver affects every website, API, and IoT device using that resolver. Art.25 NIS2 separately addresses DNS provider obligations, but Art.22 addresses the systemic risk from DNS infrastructure as a supply chain component.

3. Open-source software and software bill of materials

• High-criticality open-source components (OpenSSL, curl, log4j-class components)
• Package repositories (npm, PyPI, Maven Central)
• Cryptographic libraries

Why prioritised: The Log4Shell incident (December 2021) demonstrated that a single open-source library vulnerability can simultaneously affect millions of systems across all critical sectors. ENISA's "THREAT LANDSCAPE: SUPPLY CHAIN ATTACKS" (2021) specifically identified open-source compromise as a Tier 1 risk.

4. Semiconductor and hardware supply chains

• Processors, networking chips, security modules (TPMs, HSMs)
• Firmware for network equipment
• Trusted Execution Environments (TEEs)

Why prioritised: Hardware-level vulnerabilities (Spectre, Meltdown, Rowhammer) cannot be patched through software alone. Geopolitical concentration of semiconductor manufacturing (>90% of leading-edge chips from Taiwan/South Korea) creates strategic risk.

5. Operational technology (OT) and industrial control systems

• SCADA software, PLC firmware, industrial network protocols
• OT/IT convergence products (Purdue model collapses with cloud SCADA)

Why prioritised: OT supply chains are particularly difficult to patch and typically have 15-20 year product lifecycles. Legacy vendor relationships create lock-in that makes substitutability difficult.

How Assessments Work: Step by Step

Phase 1: Cooperation Group Selection

The Cooperation Group (comprising representatives from each Member State plus the Commission and ENISA as permanent participants) selects supply chains for assessment through its annual work programme. Selection criteria include:

• Strategic importance to EU critical infrastructure (energy, health, finance, transport)
• Provider concentration risk (few providers → systemic impact if any fails)
• Geopolitical exposure (non-EU providers with potential extraterritorial law exposure)
• Known vulnerability patterns from ENISA threat landscape reports

The work programme is published as a Cooperation Group document, typically released in Q1 of each year.

Phase 2: National Risk Assessment

The Commission invites Member States to conduct national risk assessments of the selected supply chain. Each Member State:

• Maps which domestic critical infrastructure entities use which suppliers
• Assesses national threat scenarios (geopolitical, criminal, insider)
• Identifies national-level concentration risks and single points of failure
• Submits findings to ENISA under confidentiality protections

ENISA provides the harmonised methodology and aggregates submissions.

Phase 3: ENISA Synthesis and EU-Level Report

ENISA synthesises national submissions into a Union-level risk assessment report:

• Cross-border risk scenarios that affect multiple Member States simultaneously
• Provider concentration analysis across the EU as a whole
• Threat actor attribution at the level that can be shared across governments
• Gap analysis: where national measures are inconsistent or insufficient

The report is shared with the Cooperation Group and is typically confidential or EU-RESTRICTED, though ENISA often publishes a public-facing summary.

Phase 4: Cooperation Group Recommendations

The Cooperation Group discusses the ENISA synthesis and agrees on a set of:

• Risk categories: classification of supplier risk profiles (analogous to 5G Toolbox Tier 1/2/3)
• Technical mitigations: specific security measures entities should require from suppliers
• Strategic mitigations: policy measures (diversification requirements, approved supplier lists)
• Timelines: phased implementation roadmap

These become the "Cooperation Group document" — not legally binding but representing Member State consensus.

Phase 5: Commission Implementing Act

Based on the Cooperation Group recommendations, the Commission may adopt an implementing act under Art.22(2) that:

• Designates specific supply chains as "critical" for Art.21 purposes
• Specifies minimum requirements entities must incorporate into their third-party risk management
• Sets timelines for entities to assess their suppliers against the recommendations
• Defines reporting obligations back to national competent authorities

Implementing acts are legally binding across the EU and enforced by national competent authorities under Art.32–36 NIS2.

Phase 6: NCA Implementation and Entity Obligations

National competent authorities (NCAs) translate the implementing act into national enforcement:

• Sector-specific guidance (e.g., BSI for German entities, ANSSI for French entities)
• Audit criteria for Art.21 compliance assessments
• Required supplier questionnaires or audits
• Registration updates under Art.24

For essential and important entities, the practical result is:

1. Update your ICT third-party risk register to include suppliers covered by the assessment
2. Request and review supplier documentation on Art.22-designated risks
3. Implement compensating controls where suppliers cannot meet the required risk profile
4. Report to your NCA on assessment completion within the implementing act timeline

Art.22 vs Art.21(2)(d): Two Levels, One System

A common point of confusion is the relationship between Art.22 (EU-level assessment) and Art.21(2)(d) (entity-level supply chain obligation). They are not duplicates — they operate at different scales and complement each other.

How they interact: Art.22 assessments set the floor — they identify which supply chains are systemically risky and what minimum measures are appropriate. Art.21(2)(d) requires entities to conduct their own assessments. An entity's Art.21 assessment must be consistent with Art.22 findings (once implementing acts are adopted); it cannot conclude that a supply chain designated as high-risk under Art.22 poses acceptable residual risk without documented justification.

The practical implication: monitor Art.22 outputs actively — when a new implementing act designates your cloud provider's supply chain as critical, your next Art.21 review cycle must address it explicitly.

Python SupplyChainRiskMonitor

"""
NIS2 Art.22 Supply Chain Risk Monitor
Tracks EU-level supply chain risk assessments and maps results to your vendor stack.
"""

from dataclasses import dataclass, field
from datetime import date, datetime
from enum import Enum
from typing import Optional
import json


class RiskTier(Enum):
    TIER_1_HIGH = "tier_1_high"          # Active threat actor interest, limited substitutability
    TIER_2_MEDIUM = "tier_2_medium"      # Elevated risk, mitigations available
    TIER_3_LOW = "tier_3_low"            # Standard risk, market alternatives exist
    UNASSESSED = "unassessed"            # Not yet covered by Art.22 assessment


class AssessmentStatus(Enum):
    COOPERATION_GROUP_SELECTION = "cg_selection"   # Phase 1
    NATIONAL_ASSESSMENT = "national_assessment"    # Phase 2
    ENISA_SYNTHESIS = "enisa_synthesis"            # Phase 3
    CG_RECOMMENDATIONS = "cg_recommendations"      # Phase 4
    COMMISSION_IMPLEMENTING_ACT = "implementing_act"  # Phase 5
    NCA_ENFORCEMENT = "nca_enforcement"            # Phase 6
    COMPLETED = "completed"


@dataclass
class SupplyChainAssessment:
    """Tracks a specific EU Art.22 supply chain assessment lifecycle."""
    supply_chain_id: str        # e.g., "cloud-iaas-2024", "dns-resolver-2025"
    supply_chain_name: str      # e.g., "IaaS Cloud Infrastructure"
    cg_work_programme_year: int
    current_status: AssessmentStatus
    risk_tier: RiskTier = RiskTier.UNASSESSED
    implementing_act_ref: Optional[str] = None   # e.g., "Commission IR (EU) 2025/XXXX"
    implementing_act_date: Optional[date] = None
    entity_deadline: Optional[date] = None       # Deadline for entity compliance
    key_findings: list[str] = field(default_factory=list)
    required_measures: list[str] = field(default_factory=list)

    def days_to_deadline(self) -> Optional[int]:
        if self.entity_deadline is None:
            return None
        return (self.entity_deadline - date.today()).days

    def is_overdue(self) -> bool:
        if self.entity_deadline is None:
            return False
        return date.today() > self.entity_deadline


@dataclass
class Vendor:
    """A vendor in your ICT supply chain."""
    vendor_id: str
    name: str
    service_category: str       # e.g., "cloud-iaas", "dns-resolver", "oss-library"
    criticality: str            # "critical", "important", "standard"
    eu_establishment: bool      # Is the vendor established in the EU?
    contracts_in_scope: list[str] = field(default_factory=list)
    current_risk_tier: RiskTier = RiskTier.UNASSESSED
    last_assessed: Optional[date] = None
    assessment_notes: str = ""


class SupplyChainRiskMonitor:
    """
    Monitors Art.22 assessments and maps conclusions to your vendor stack.
    
    Use case: When the EU publishes findings on cloud IaaS supply chains,
    this tool maps which of your vendors are affected and what you must do.
    """

    def __init__(self, entity_name: str, entity_type: str):
        self.entity_name = entity_name
        self.entity_type = entity_type   # "essential" | "important"
        self.vendors: dict[str, Vendor] = {}
        self.assessments: dict[str, SupplyChainAssessment] = {}
        self.affected_vendors: list[dict] = []

    def register_vendor(self, vendor: Vendor) -> None:
        self.vendors[vendor.vendor_id] = vendor

    def register_assessment(self, assessment: SupplyChainAssessment) -> None:
        self.assessments[assessment.supply_chain_id] = assessment

    def map_assessment_to_vendors(
        self,
        supply_chain_id: str
    ) -> list[dict]:
        """
        When an Art.22 assessment completes, identify which of your vendors
        fall within the assessed supply chain category.
        """
        assessment = self.assessments.get(supply_chain_id)
        if not assessment:
            return []

        affected = []
        for vendor in self.vendors.values():
            # Map vendor service category to assessment supply chain
            if self._vendor_in_supply_chain(vendor, assessment):
                # Update vendor risk tier based on assessment findings
                vendor.current_risk_tier = assessment.risk_tier
                vendor.last_assessed = date.today()

                gap_analysis = self._gap_analysis(vendor, assessment)
                affected.append({
                    "vendor": vendor.name,
                    "vendor_id": vendor.vendor_id,
                    "service_category": vendor.service_category,
                    "risk_tier": assessment.risk_tier.value,
                    "days_to_deadline": assessment.days_to_deadline(),
                    "required_measures": assessment.required_measures,
                    "gaps": gap_analysis,
                    "action_required": len(gap_analysis) > 0,
                })

        self.affected_vendors = affected
        return affected

    def _vendor_in_supply_chain(
        self,
        vendor: Vendor,
        assessment: SupplyChainAssessment
    ) -> bool:
        """Map vendor service category to assessed supply chain."""
        # Simplified mapping — extend based on your taxonomy
        category_map = {
            "cloud-iaas-2024": ["cloud-iaas", "cloud-paas", "colocation"],
            "dns-resolver-2025": ["dns-resolver", "dns-authoritative", "cdn"],
            "oss-library-2025": ["oss-library", "package-registry", "build-tool"],
        }
        relevant_categories = category_map.get(assessment.supply_chain_id, [])
        return vendor.service_category in relevant_categories

    def _gap_analysis(
        self,
        vendor: Vendor,
        assessment: SupplyChainAssessment
    ) -> list[str]:
        """
        Compare required measures against vendor's current documentation.
        In production: integrate with your vendor questionnaire system.
        """
        gaps = []
        if not vendor.last_assessed:
            gaps.append("No prior risk assessment on file — initial assessment required")
        if not vendor.eu_establishment and assessment.risk_tier == RiskTier.TIER_1_HIGH:
            gaps.append(
                "Non-EU vendor in Tier 1 supply chain — "
                "legal risk under CLOUD Act / foreign jurisdiction laws"
            )
        if vendor.criticality == "critical" and not vendor.contracts_in_scope:
            gaps.append("Critical vendor with no NIS2-aligned contract provisions on file")
        return gaps

    def generate_nca_report(self) -> dict:
        """
        Generate the report structure for NCA submission when implementing
        act requires entities to report their supply chain assessment results.
        """
        high_risk_vendors = [
            v for v in self.affected_vendors
            if v["risk_tier"] == RiskTier.TIER_1_HIGH.value
        ]
        overdue_deadlines = [
            v for v in self.affected_vendors
            if v.get("days_to_deadline") is not None and v["days_to_deadline"] < 0
        ]

        return {
            "report_date": date.today().isoformat(),
            "entity_name": self.entity_name,
            "entity_type": self.entity_type,
            "total_vendors_assessed": len(self.affected_vendors),
            "tier_1_high_risk_count": len(high_risk_vendors),
            "tier_1_vendors": [v["vendor"] for v in high_risk_vendors],
            "overdue_compliance_actions": len(overdue_deadlines),
            "vendors_requiring_action": [
                v for v in self.affected_vendors if v["action_required"]
            ],
            "summary": (
                f"Assessment complete: {len(self.affected_vendors)} vendors assessed, "
                f"{len(high_risk_vendors)} in Tier 1 (high risk), "
                f"{len(overdue_deadlines)} compliance deadlines overdue."
            ),
        }


# --- Usage Example ---

if __name__ == "__main__":
    monitor = SupplyChainRiskMonitor(
        entity_name="AcmeSaaS GmbH",
        entity_type="important",  # or "essential"
    )

    # Register your vendor stack
    monitor.register_vendor(Vendor(
        vendor_id="aws-eu-west",
        name="AWS EU (Frankfurt)",
        service_category="cloud-iaas",
        criticality="critical",
        eu_establishment=True,   # AWS EU ops, but parent is US
        contracts_in_scope=["aws-dpa-2023"],
    ))
    monitor.register_vendor(Vendor(
        vendor_id="cloudflare-dns",
        name="Cloudflare 1.1.1.1",
        service_category="dns-resolver",
        criticality="important",
        eu_establishment=False,  # US-incorporated
        contracts_in_scope=[],
    ))

    # Register Art.22 assessments (update as EU publishes)
    monitor.register_assessment(SupplyChainAssessment(
        supply_chain_id="cloud-iaas-2024",
        supply_chain_name="IaaS Cloud Infrastructure",
        cg_work_programme_year=2024,
        current_status=AssessmentStatus.COMMISSION_IMPLEMENTING_ACT,
        risk_tier=RiskTier.TIER_2_MEDIUM,
        implementing_act_ref="Commission IR (EU) 2025/XXXX",
        implementing_act_date=date(2025, 3, 1),
        entity_deadline=date(2025, 9, 1),
        key_findings=[
            "High provider concentration: top 3 providers serve 73% of EU critical sector workloads",
            "US CLOUD Act jurisdiction risk for non-EU-established providers",
            "Subprocessor chains extend 4-6 levels deep — limited entity visibility",
        ],
        required_measures=[
            "Maintain documented multi-cloud exit plan (RTO ≤ 72h for critical functions)",
            "Require cloud provider CLOUD Act risk disclosure in contract",
            "Map sub-processor chain to at least 3 levels for critical workloads",
            "Conduct annual supplier audit or accept SOC2 Type II / ISO 27001 equivalent",
        ],
    ))

    # Run assessment mapping
    affected = monitor.map_assessment_to_vendors("cloud-iaas-2024")
    print("=== Art.22 Assessment Impact ===")
    for vendor in affected:
        print(f"\nVendor: {vendor['vendor']}")
        print(f"  Risk Tier: {vendor['risk_tier']}")
        print(f"  Days to Deadline: {vendor['days_to_deadline']}")
        if vendor["gaps"]:
            print(f"  Gaps: {', '.join(vendor['gaps'])}")
        if vendor["required_measures"]:
            print(f"  Required Measures:")
            for m in vendor["required_measures"]:
                print(f"    - {m}")

    # Generate NCA report
    report = monitor.generate_nca_report()
    print("\n=== NCA Submission Report ===")
    print(json.dumps(report, indent=2, default=str))

ENISA's Art.22 Work: What's Been Published

ENISA has been producing supply chain security assessments independently of the Art.22 formal mechanism since before NIS2 entered force. These reports serve as the evidence base for Cooperation Group selection decisions and provide practical guidance even before implementing acts are adopted:

ENISA Threat Landscape for Supply Chain Attacks (2021) The foundational document. Identified 24 supply chain attack techniques, classified attackers by sophistication, and ranked target asset types (software, hardware, cloud, managed services). This directly shaped Art.22's design.

ENISA Supply Chain Security Good Practices for EU/EEA Digital Infrastructure Operators (2022) Practical guidance for network and digital infrastructure operators. Covers vendor due diligence, contractual controls, monitoring, and incident response for supply chain events.

ENISA Cloud Security for Healthcare (2023) Sector-specific supply chain risk assessment covering IaaS/PaaS/SaaS in healthcare — demonstrates how Art.22 sector assessments work in practice.

ENISA 5G Security Certification (ongoing) Ongoing work extending the 5G Toolbox with cybersecurity certification requirements for network equipment — the implementation phase of the original 5G supply chain assessment.

How to monitor: ENISA publishes work programme documents and reports at enisa.europa.eu. The Cooperation Group work programme (updated annually, usually December for the following year) lists planned Art.22 assessment topics.

NIS2 × DORA × CRA Cross-Map

Art.22 assessments have implications that extend beyond NIS2 into DORA and the Cyber Resilience Act:

Key cross-framework interaction: When an Art.22 implementing act designates cloud IaaS as a critical supply chain, this simultaneously:

1. NIS2 entities must update their Art.21(2)(d) vendor assessment to address the designated risks
2. DORA financial entities must update their Art.28 ICT third-party risk policy (the DORA Art.28 register overlaps with Art.22 designated supply chains)
3. CRA manufacturers who use the designated cloud infrastructure for product development or delivery must assess whether CRA Art.13 supply chain obligations are triggered

A unified supply chain risk register (maintained under DORA Art.28 for financial entities, or as part of Art.21 documentation for other NIS2 entities) can serve all three frameworks simultaneously if structured correctly.

What SaaS Developers Must Do

If You Are an Essential or Important Entity

Ongoing (before implementing acts):

1. Monitor the Cooperation Group work programme — know which supply chains are being assessed so you can begin voluntary assessment early.

2. Maintain a vendor inventory categorised by the same taxonomy the Cooperation Group uses (cloud IaaS, DNS, OSS libraries, hardware). This makes implementing act mapping mechanical rather than ad hoc.

3. Include Art.22 clause in vendor contracts: require vendors to notify you if they become subject to an Art.22 assessment or implementing act, and to cooperate with your resulting risk assessment.

4. Update Art.21 risk management documentation to include an Art.22 monitoring section — this demonstrates to NCAs that you have a systemic view, not just an entity-level checklist.

When an implementing act is adopted:

1. Map assessed supply chain to your vendor stack within 30 days — identify all vendors falling within the designated category.

2. Conduct gap assessment — compare required measures in the implementing act against your current vendor documentation (contracts, audit reports, certifications).

3. Implement remediations within the implementing act deadline — typically 6–18 months depending on the complexity of required measures.

4. Update your NCA registration if the implementing act requires notification of high-risk vendor relationships.

If You Are an ICT Supplier in a Supply Chain Being Assessed

1. Participate voluntarily in ENISA consultations — ENISA typically publishes calls for evidence when conducting supply chain assessments. Early engagement gives you visibility into what requirements are coming.

2. Prepare documentation proactively — assessments will generate customer requests for security certifications, SBOM, audit rights, data residency confirmations. Having these ready reduces friction.

3. Monitor your CTPP designation risk (if you serve EU financial entities) — Art.22 findings for cloud supply chains often inform DORA Art.31 CTPP designation decisions.

20-Item Art.22 Compliance Checklist

Understanding and Monitoring (Items 1–5)

• 1. Assigned internal owner for Art.22 monitoring (typically CISO or Vendor Risk Manager)
• 2. Subscribed to ENISA publications and Cooperation Group document releases
• 3. Reviewing Cooperation Group annual work programme each January for upcoming assessments
• 4. Mapped your vendor stack to Cooperation Group supply chain categories (cloud, DNS, OSS, OT, semiconductor)
• 5. Documented whether your entity is essential or important (determines NCA enforcement scope)

Vendor Inventory and Contracts (Items 6–10)

• 6. Maintained ICT vendor inventory with service category, criticality, and EU establishment status
• 7. Contract review: Art.22 notification clause included in critical vendor agreements
• 8. Contract review: audit rights and supplier cooperation with NCA requests documented
• 9. SBOM available or requested for critical software vendors
• 10. Multi-cloud or multi-vendor exit plan documented for Tier 1 supply chain categories

Art.21 Integration (Items 11–15)

• 11. Art.21 risk management policy explicitly references Art.22 as an input to supply chain risk assessment
• 12. Annual Art.21 review cycle includes an Art.22 implementing act check
• 13. Proportionate measures documented per vendor criticality tier (not one-size-all)
• 14. Board or management body informed of Art.22 assessment conclusions (Art.20 obligation)
• 15. Incident response plan includes scenario for compromised supply chain component (software supply chain attack, vendor breach)

NCA Reporting and Audit Readiness (Items 16–20)

• 16. NCA registration updated if implementing act requires high-risk vendor disclosure
• 17. Art.22 assessment results documented and ready for NCA audit — evidence file prepared
• 18. Gap analysis between implementing act requirements and current vendor controls completed within deadline
• 19. Remediation plan with owners and timelines documented for each identified gap
• 20. Cross-framework consistency: Art.22 findings reflected in DORA Art.28 register (financial entities) or CRA product documentation (ICT manufacturers)

Why Hosting on EU Infrastructure Simplifies Art.22 Compliance

When an Art.22 implementing act designates cloud IaaS supply chains, one of the most common gaps identified is jurisdiction risk: US-incorporated cloud providers are subject to the CLOUD Act, which can require disclosure of European customer data to US law enforcement without the customer's consent or an EU legal basis.

Hosting on genuinely EU-established infrastructure — where the legal entity, operations, and data residency are all within the EU — eliminates a category of Art.22 gap before the assessment even completes. For essential entities whose NCA will audit Art.21(2)(d) supply chain risk, an EU cloud provider significantly reduces the documentation burden: there is no CLOUD Act risk to mitigate, no extraterritorial jurisdiction clause to negotiate, and no jurisdiction conflict analysis required.

sota.io is built for exactly this scenario: a European PaaS platform, operated under EU law, designed for teams that need to demonstrate clean supply chain provenance in NIS2 Art.22 compliance documents without the overhead of negotiating bespoke data protection addenda with hyperscale US providers.

Summary

NIS2 Art.22 is the EU's systemic supply chain risk management mechanism — the layer above entity-level Art.21(2)(d) that identifies which supply chains pose EU-wide risk and translates that into binding requirements for entities. The 5G Toolbox proved the model works. Now the same mechanism applies to cloud, DNS, open-source, hardware, and OT supply chains.

For SaaS developers, Art.22 compliance is not passive monitoring. It requires:

1. An active vendor monitoring capability that maps to Cooperation Group supply chain categories
2. Contract provisions requiring vendor cooperation when assessments are published
3. Integration of implementing act outputs into the Art.21 annual review cycle
4. Documentation readiness for NCA audits that will increasingly reference Art.22 findings

The Python SupplyChainRiskMonitor above gives you a practical starting point — extend it with your actual vendor list, connect it to your contract management system, and build Art.22 monitoring into your annual compliance calendar rather than treating it as a one-time task.

See Also:

• NIS2 Art.21(2)(d): Supply Chain Risk Management at Entity Level
• NIS2 Art.26: Coordinated Vulnerability Disclosure (CVD)
• DORA Art.28–30: ICT Third-Party Risk
• ENISA NIS2 Technical Guidelines: Art.21 Security Measures