Article 22: Union level coordinated security risk assessments of critical supply chains

Article 22 requires you to be ready to support EU-wide, coordinated security risk assessments of critical ICT supply chains led by the Cooperation Group with the Commission and ENISA. Operationally, you must know your critical ICT dependencies, assess their supply-chain risks (technical and non-technical), and be able to produce exam-ready evidence quickly if your technologies or providers fall in scope. (Directive (EU) 2022/2555, Article 22)

Key takeaways:

• Build and maintain an inventory of critical ICT services, systems, products, and the third parties behind them.
• Run supply-chain risk assessments that include technical and relevant non-technical factors, with clear owners and remediation tracking.
• Prepare a “rapid-response evidence pack” so you can answer coordinated assessment requests without scrambling.

Article 22 is not a day-to-day control with a single checkbox. It is an EU-level mechanism that can trigger coordinated security risk assessments of specific critical ICT supply chains. If your organization depends on a supply chain that becomes a focus area (for example, a widely used ICT product, managed service, or system component), you may be asked, directly or indirectly through your national authority, to provide structured information and evidence about your dependency, risk posture, and mitigations. (Directive (EU) 2022/2555, Article 22)

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing Article 22 is to treat it as a readiness requirement: establish clear scope, maintain a defensible view of critical ICT dependencies, and keep current risk assessments and remediation status for those dependencies. This is the same operational discipline you need for strong third-party risk management (TPRM), but with two differences: (1) “critical” scope matters more than “all vendors,” and (2) you must be prepared to discuss non-technical risk factors where relevant (for example, governance and exposure linked to the supply chain). (Directive (EU) 2022/2555, Article 22)

This page gives you requirement-level guidance you can assign to control owners, implement quickly, and defend in supervisory conversations.

Requirement: Article 22 readiness for Union-level coordinated supply-chain risk assessments

Plain-English interpretation (what the requirement means in practice)
Article 22 empowers the EU Cooperation Group, working with the Commission and ENISA, to conduct coordinated security risk assessments of the supply chains for specific critical ICT services, ICT systems, or ICT products, considering technical and, where relevant, non-technical risk factors. (Directive (EU) 2022/2555, Article 22)

For operators, the obligation is indirect but real: if your critical ICT stack includes technologies or third parties that become subject to a coordinated assessment, regulators will expect you to (a) know what you run, (b) understand the upstream supply chain exposure, (c) show the current risk position and mitigations, and (d) respond fast with consistent evidence.

Who it applies to (entity and operational context)

Entity scope: Organizations in NIS 2 scope (typically “essential” and “important” entities under national transposition) that rely on ICT services/systems/products that could be considered critical in their operations. Article 22 itself describes EU-level assessment activity rather than a standalone organizational duty, but supervised entities should implement readiness controls so they can support or comply with resulting supervisory actions. (Directive (EU) 2022/2555, Article 22; Directive (EU) 2022/2555)

Operational scope: Any function that owns, procures, operates, or assures critical ICT, including:

• Security and IT operations (asset, vulnerability, configuration, logging)
• Procurement and vendor management (contracts, SLAs, supplier due diligence)
• Product/engineering (SBOM expectations, secure SDLC for embedded components)
• Legal/compliance (regulatory correspondence, evidence production, records)

Practical trigger: A coordinated assessment focuses on a specific supply chain. Your prep work must let you determine quickly whether you use the in-scope ICT service/system/product and, if yes, produce the evidence pack.

Regulatory text

Excerpt (Article 22(1)): “The Cooperation Group, in cooperation with the Commission and ENISA, may carry out coordinated security risk assessments of specific critical ICT services, ICT systems or ICT products supply chains, taking into account technical and, where relevant, non-technical risk factors.” (Directive (EU) 2022/2555, Article 22)

What you, as an operator, must do with this text

• Treat it as a standing requirement to maintain assessment readiness for critical ICT supply chains.
• Ensure your internal risk assessment methodology explicitly covers supply-chain risk and can incorporate non-technical risk factors when relevant to a specific supply chain under review.
• Ensure governance is tight enough that you can answer “what is critical, who owns it, what risks are open, what mitigations exist, and what assurance supports that view” without re-building the story during an exam.

What you actually need to do (step-by-step)

Use the steps below as an implementation checklist you can assign to control owners.

1) Define “critical ICT” for your organization (and document it)

Create a short, defensible definition that matches how your business runs. Example criteria:

• Supports core service delivery or safety-critical operations
• Handles sensitive data or privileged access
• Single point of failure with limited substitutes
• High concentration risk (widely deployed across the estate)

Output: “Critical ICT Scoping Standard” approved by Security + IT + Compliance, mapped to your enterprise risk approach. (Directive (EU) 2022/2555)

2) Build a dependency map for critical ICT services, systems, and products

You need a practical inventory that answers:

• What is the ICT service/system/product?
• Who provides it (third party name, legal entity, subprocessor chain where known)?
• Where is it deployed (business units, environments)?
• What privileges does it hold (admin access, network reach, data access)?
• What is the operational fallback if it fails?

Operator tip: Don’t boil the ocean. Start with critical dependencies and expand outward.

Outputs:

• Critical ICT register (single source of truth)
• Third-party dependency mapping for each critical item (primary provider plus key downstream dependencies where known)

3) Run a supply-chain security risk assessment for each critical dependency

Your assessment must cover technical risk factors and non-technical risk factors where relevant to that supply chain. (Directive (EU) 2022/2555, Article 22)

A workable assessment template should include:

• Threat scenarios (compromise of update mechanism, MSP remote access misuse, component vulnerability)
• Security controls and assurance signals (pen test summaries, SOC 2/ISO evidence if available, internal testing outcomes)
• Concentration and substitutability (exit feasibility, alternatives)
• Non-technical factors (where relevant): governance transparency, ownership structure risk, geopolitical exposure, legal constraints that affect incident response cooperation

Outputs:

• Completed risk assessment per critical supply chain
• Risk rating and rationale
• Action plan with control owners and due dates

4) Convert findings into tracked remediation (and tie it to procurement)

The fastest way to fail an exam is to show you can identify supply-chain risk but cannot show closure discipline.

Operationalize remediation through:

• A single risk register workflow for third-party and technology risks
• Contracting guardrails for critical ICT (security requirements, audit rights, incident notification, change/update controls)
• Assurance cadence tied to criticality (evidence refresh, performance and incident trend review)

Outputs:

• Remediation tracker (open/closed, compensating controls, exceptions with approvals)
• Contract templates and addenda for critical ICT suppliers
• Exception register with expiry dates and owner sign-off

5) Create a “coordinated assessment response pack”

Build a ready folder (GRC system workspace is ideal) that you can share internally in hours, not weeks. Include:

• Your critical ICT register extract
• Dependency map for the in-scope product/service/system
• Latest supply-chain risk assessment and remediation status
• Incident handling workflow and reporting decision tree (so you can show operational readiness)
• Contact list (security, procurement, legal, comms) and an evidence index

Daydream fit (earned mention): Many teams store this material across spreadsheets, ticketing, and procurement tools. Daydream can act as the system of record for obligation tracking, control ownership, and evidence packaging so your response pack stays current instead of becoming a quarterly scramble. (Directive (EU) 2022/2555)

Required evidence and artifacts to retain

Keep artifacts in an exam-ready format (dated, approved, attributable to owners). Minimum set:

• Critical ICT definition and scoping criteria
• Critical ICT register and dependency maps
• Supply-chain risk assessments (with technical and, where relevant, non-technical sections) (Directive (EU) 2022/2555, Article 22)
• Risk register entries and remediation tickets with status history
• Third-party due diligence records for critical providers (security questionnaires, assurance reports, meeting notes)
• Contract clauses for critical ICT suppliers (incident notification, audit rights, subcontractor controls)
• Governance evidence: ownership, approvals, periodic review minutes

Common exam/audit questions and hangups

Expect questions like:

1. “Show me your critical ICT dependencies and why they are critical.”
   Hangup: criticality defined vaguely or inconsistently across teams.
2. “How do you assess supply-chain risk for this ICT product/service?”
   Hangup: assessments exist but don’t address upstream dependencies or non-technical factors where relevant. (Directive (EU) 2022/2555, Article 22)
3. “What are your top open risks tied to critical third parties, and what is the remediation status?”
   Hangup: no single remediation tracker; exceptions have no expiry.
4. “Can you produce evidence quickly?”
   Hangup: evidence scattered, outdated, or not attributable to an owner.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating Article 22 as “EU does this, not us.”
  Fix: implement readiness controls anyway; coordinated assessments become supervisory asks downstream. (Directive (EU) 2022/2555, Article 22)
• Mistake: Inventory without dependency mapping.
  Fix: require each critical ICT entry to list the provider, service model, privileged access, and known key subcontractors.
• Mistake: Risk assessments that ignore non-technical factors.
  Fix: add a “non-technical factors (if relevant)” section with explicit guidance for when to complete it. (Directive (EU) 2022/2555, Article 22)
• Mistake: No linkage between risk findings and procurement actions.
  Fix: add contracting playbooks for critical ICT and require remediation gating for renewals.
• Mistake: Evidence that cannot be authenticated.
  Fix: store signed approvals, meeting minutes, and ticket history. Screenshots without context do not hold up.

Enforcement context and risk implications

No public enforcement cases were provided in the source materials for Article 22, so you should plan based on supervisory expectations implied by NIS 2’s structure: authorities will test whether your governance and operational controls can support regulatory coordination and risk management across critical dependencies. (Directive (EU) 2022/2555)

Risk to plan for:

• Regulatory friction risk: slow or inconsistent responses when a coordinated assessment touches your stack.
• Operational risk: concentration in a critical ICT supplier with weak assurance signals.
• Board risk: inability to explain exposure and mitigation for a widely used critical product/service under scrutiny.

Practical 30/60/90-day execution plan

Use this as a sequencing tool. Adjust based on whether you already have mature TPRM and asset management.

First 30 days (Immediate)

• Assign an executive owner (security or GRC) and a procurement counterpart for “critical ICT supply-chain assessments.” (Directive (EU) 2022/2555)
• Draft and approve the “critical ICT” definition and scoping criteria.
• Stand up the critical ICT register with an initial cut from CMDB/procurement/SaaS catalogs.
• Identify the top critical third parties (providers with privileged access, core operations dependency, or sensitive data access).

Days 31–60 (Near-term)

• Complete dependency mapping for each critical ICT entry (provider, access model, data flows, fallback).
• Run supply-chain risk assessments for the highest criticality items, including non-technical factors where relevant. (Directive (EU) 2022/2555, Article 22)
• Create a remediation workflow: risk register linkage, ticketing, exception approvals.
• Standardize contract security clauses for critical ICT renewals.

Days 61–90 (Operationalize)

• Build the coordinated assessment response pack structure and evidence index.
• Tabletop a “coordinated assessment request” scenario: can you identify affected products and produce evidence fast?
• Report to leadership: critical dependency list, top open supply-chain risks, remediation progress, and any concentration risks that need decisions.
• If you use Daydream (or similar), configure obligation tracking and evidence mapping so artifacts stay current between review cycles. (Directive (EU) 2022/2555)

Frequently Asked Questions

Does Article 22 force my organization to perform an EU-level risk assessment?

Article 22 states the Cooperation Group, with the Commission and ENISA, may conduct coordinated assessments. Your practical duty is readiness: maintain defensible inventories, supply-chain risk assessments, and evidence so you can respond if your critical supply chain becomes in scope. (Directive (EU) 2022/2555, Article 22)

What counts as “non-technical risk factors” in a supply-chain assessment?

Article 22 requires considering non-technical factors where relevant, but it does not enumerate them in the provided excerpt. In practice, document governance, ownership/organizational risk, and external constraints that could affect secure operations or incident cooperation for that supply chain. (Directive (EU) 2022/2555, Article 22)

We have a TPRM program. What changes for Article 22?

Narrow scope to “critical ICT” and deepen the dependency mapping and evidence packaging. Article 22 readiness depends on proving you understand upstream supply-chain exposure for the specific products/services that are critical to your operations. (Directive (EU) 2022/2555, Article 22)

How do I decide which ICT services/systems/products are “critical” without over-scoping?

Use business impact and concentration as primary filters, then validate with IT and security owners. Document the criteria and apply it consistently so your register is defensible during supervisory review. (Directive (EU) 2022/2555)

What evidence should I be able to produce quickly if asked about a specific supplier?

You should be able to produce the dependency map, the latest supply-chain risk assessment, open risk/remediation status, and relevant contract terms (security obligations, incident notification, audit rights). Package these in a pre-built evidence index. (Directive (EU) 2022/2555, Article 22)

How can Daydream help without turning this into a tool-only project?

Use Daydream to keep an obligation register, map control owners, and attach evidence artifacts to each critical dependency and risk assessment. The goal is faster, consistent responses, not more process. (Directive (EU) 2022/2555)