Supply Chain and Third-Party Risk Under NIS2

1. Positioning NIS2 and Supply Chain Risk

Where does supply chain fit in NIS2?

The NIS2 Directive (Directive (EU) 2022/2555), which entered into force in 2023 and must be transposed by Member States by 17 October 2024, significantly elevates supply chain and third‑party cybersecurity.

Key context (relative to today – late 2025):

• NIS2 replaced the original NIS Directive (2016) and expanded scope to many more entities ("essential" and "important" entities).
• Most EU Member States have now transposed NIS2 into national law or are in the final stages. Exact obligations may be specified or tightened by national law, but the minimum floor is set by NIS2.
• Supply chain security appears explicitly in Article 21(2)(d) and is tightly linked with governance and management accountability (previous module) and incident reporting (previous module).

Why supply chain risk is central under NIS2

NIS2 recognizes that:

• Attacks often cascade through suppliers (e.g., managed service providers, software updates, cloud platforms).
• Even if your internal security is strong, weak vendors can be the attack path.
• Critical sectors now depend on complex, multi‑tier, global supply chains.

Therefore, NIS2 requires covered entities to:

1. Assess and manage cybersecurity risks in the supply chain and supplier relationships.
2. Integrate supply chain risk into overall risk management, not treat it as a separate or optional activity.
3. Use contractual arrangements and ongoing monitoring to maintain an adequate security posture across suppliers.

Learning focus of this module:

• Identify NIS2 obligations related to supply chain and third‑party risk.
• Design assessment, contracting, and monitoring processes aligned with NIS2.
• Work through edge cases: cloud, MSPs, SaaS, open‑source, and 4th/5th‑party risk.

Keep in mind: NIS2 sets outcome‑oriented obligations. It does not prescribe one fixed process, but you must be able to justify your approach to regulators and, in some Member States, to auditors.

2. Core NIS2 Supply Chain Obligations (Legal Lens)

Key provisions you must map to your program

Under NIS2, supply chain risk is mainly anchored in Article 21 – Cybersecurity risk‑management measures. For advanced study, read the article in full, but the most relevant parts are:

1. Art. 21(1) – Entities must take appropriate and proportionate technical, operational and organisational measures to manage cybersecurity risks and prevent or minimize the impact of incidents.

1. Art. 21(2)(d) – These measures must include:

> “supply chain security, including security‑related aspects concerning the relationships between each entity and its direct suppliers or service providers”

1. Art. 21(2)(a–l) – Other required measures (e.g., incident handling, policies, training, cryptography, etc.) extend into supplier relationships. For example:

• Incident handling requirements imply incident clauses and notification in contracts.
• Business continuity and crisis management imply supplier continuity and exit strategies.

1. Art. 23 – Use of managed security services / CSIRTs / SOCs – If you outsource security operations, you still retain accountability for compliance.

1. Art. 32–34 – Supervision and enforcement – Supervisory authorities can:

• Request evidence of your supplier risk management, including contracts and risk assessments.
• Impose corrective measures or administrative fines if third‑party risk is mismanaged.

1. Management accountability (Art. 20) – Management bodies must approve and oversee cybersecurity risk‑management measures, including supply chain. Failure can lead to personal liability under some national laws.

Practical implication

You must be able to show, in a structured way:

• How you identify critical suppliers and services.
• How you assess and accept/mitigate their risks.
• How you embed security into contracts and procurement.
• How you monitor suppliers over time.

The rest of this module will translate these legal requirements into a concrete, stepwise process.

3. Map Your Supply Chain: Thought Exercise

Exercise: Identify your critical external dependencies

Imagine you are the CISO of a mid‑size EU energy provider classified as an essential entity under NIS2.

1. List 5–7 categories of third parties you depend on for critical or important functions. Examples might include:

• Cloud infrastructure (IaaS/PaaS)
• SaaS for SCADA data analytics
• Managed Security Service Provider (MSSP) or SOC‑as‑a‑Service
• Field maintenance contractors with remote access
• Hardware suppliers (e.g., smart meters, routers)
• Software vendors providing firmware updates

1. For each category, answer:

• What could go wrong if this third party is compromised or fails?
• Would that scenario likely meet NIS2’s incident thresholds (e.g., significant disruption to services, impact on public safety)?

1. Based on your answers, classify each category:

• Tier 1 – Critical: Incident at the supplier would almost certainly be a reportable NIS2 incident for you.
• Tier 2 – Important: Incident could be significant but may be contained or non‑reportable.
• Tier 3 – Non‑critical: Low impact; mostly administrative or reversible.

> Your task: On paper or in a note, sketch a simple 3‑column table: Supplier Category | Worst‑case impact | Tier (1–3).

>

> This will be the basis for designing risk‑based controls in later steps.

Reflect: Which categories surprised you when you realized how critical they are? How many of them are not traditionally treated as “IT suppliers” (e.g., physical maintenance contractors)?

4. Designing a NIS2‑Aligned Third‑Party Risk Lifecycle

From law to process: the lifecycle view

To operationalize Art. 21(2)(d), structure your third‑party risk management (TPRM) as a lifecycle:

1. Scoping and classification

• Maintain an authoritative inventory of third parties (vendors, service providers, partners, joint ventures, key open‑source projects if business‑critical).
• Classify each by criticality and data/system access, informed by your earlier exercise.

1. Pre‑contract risk assessment

• Perform risk‑based due diligence before signing or renewing contracts.
• Depth of assessment scales with criticality (Tier 1 vs Tier 3).

1. Contracting and security assurances

• Embed security, incident, and audit clauses in contracts.
• Align with NIS2 reporting deadlines and your governance framework.

1. Onboarding and technical integration

• Enforce least privilege and segmentation for supplier access.
• Verify that contractual promises are backed by technical controls.

1. Ongoing monitoring and review

• Monitor for security incidents, performance degradations, and changes (e.g., ownership changes, sub‑processor changes).
• Re‑assess risk periodically and after major incidents.

1. Termination and exit strategy

• Ensure secure data return/erasure.
• Remove access, revoke credentials, and decommission integrations.

NIS2 alignment checkpoints

At each stage, ask:

• Would a regulator accept this as “appropriate and proportionate” given our risk profile?
• Could we show documentation (policies, assessments, contracts, logs) during a supervisory inspection?

In the next steps, we zoom into assessment, contracting, and monitoring with concrete examples.

5. Vendor Risk Assessment: Deep‑Dive with Edge Cases

Example: Structured pre‑contract assessment

Assume you are evaluating a new Managed Security Service Provider (MSSP) that will:

• Monitor your networks and OT environment
• Have privileged access to logs and some production systems

1. Define risk factors (aligned with NIS2 themes)

Typical factors and advanced considerations:

• Service criticality
• Would MSSP downtime or compromise impair your ability to detect/respond to incidents (Art. 21 incident handling)?

• Data sensitivity & access
• Does the MSSP access personal data, trade secrets, or operational data that, if leaked, could cause significant disruption?

• Connectivity and privilege
• Does the MSSP have VPN access, jump‑hosts, or remote admin rights into critical systems?
• Are they a potential single point of failure or a concentration risk (many entities using the same MSSP)?

• Supply chain depth
• Does the MSSP itself rely on sub‑processors (e.g., cloud SIEM, ticketing SaaS)?
• How transparent are they about 4th‑party dependencies?

• Jurisdiction and legal constraints
• Where is the MSSP headquartered and where is data processed?
• Are there conflicting legal regimes (e.g., non‑EU access to EU data)?

• Security posture evidence
• Independent certifications (e.g., ISO/IEC 27001, SOC 2) – but do not treat them as sufficient.
• Pen‑test summaries, vulnerability management metrics, incident history.

2. Assessment methods (risk‑based)

For a Tier 1 (critical) MSSP under NIS2, you might:

• Send a detailed security questionnaire mapped to NIS2 measures (e.g., access control, incident management, business continuity).
• Request policy and procedure excerpts (e.g., incident response, secure development).
• Conduct a technical workshop with their SOC architects.
• For very high‑risk scenarios, negotiate on‑site or remote audits (or third‑party audit reports with sufficient depth).

3. Risk decision and documentation

Document:

• Inherent risk (before controls) and residual risk (after proposed controls and contract clauses).
• Explicit risk acceptance/mitigation/avoidance decision, signed off at an appropriate management level (link to Art. 20 governance).

If residual risk remains high, you may:

• Impose additional controls (e.g., stricter network segmentation, dedicated VPNs, just‑in‑time access).
• Decide to split services across multiple providers to reduce concentration risk.

This documented assessment is a key artifact if a regulator investigates why you chose this MSSP after a later incident.

6. Quick Check: Proportionate Due Diligence

Test your understanding of risk‑based assessment depth under NIS2.

7. Contractual Clauses and Security Assurances

Turning risk requirements into binding obligations

After assessment, you must encode expectations into contracts. Under NIS2, regulators will expect to see contractual alignment with your obligations, especially for critical and important suppliers.

#### Core security clauses (baseline)

For NIS2‑relevant suppliers, contracts should typically include:

1. Security standards clause

• Supplier must implement and maintain security measures at least equivalent to:
• Your internal policies, and
• Industry standards relevant to the service (e.g., ISO/IEC 27001, IEC 62443 for OT, where applicable).

1. Incident notification and cooperation clause

• Supplier must notify you without undue delay of any incident that:
• Affects services you rely on, or
• Could lead to a NIS2‑relevant incident for you.
• Notification timelines should be shorter than your legal deadlines (e.g., internal target: within 2–4 hours of detection) so you can meet NIS2 reporting timeframes.
• Supplier must cooperate in investigations, provide logs, and support communications with CSIRTs/authorities.

1. Access control and segmentation clause

• Clear rules on who can access your systems/data, with:
• Named roles or groups
• MFA requirements
• Logging and monitoring obligations

1. Sub‑processor / sub‑supplier clause

• Supplier must:
• Disclose sub‑processors or critical sub‑suppliers.
• Flow down equivalent security obligations to them.
• Notify you of changes and, for critical services, give you a right to object in certain cases.

1. Audit and assurance clause

• Right to obtain independent assurance:
• Security reports, certifications, audit summaries.
• For high‑risk suppliers: right to conduct or commission audits, subject to safeguards.

1. Business continuity and exit clause

• Requirements for service continuity, backup, disaster recovery.
• Exit support: secure data return/erasure, transition assistance.

#### Edge cases

• Big cloud providers (hyperscalers) often resist bespoke clauses. Under NIS2, you must:
• Assess whether their standard commitments are sufficient for your risk profile.
• Add compensating controls (e.g., encryption, architecture changes) where contract flexibility is limited.

• Open‑source software: There may be no contract at all.
• You then rely on internal controls (code review, SBOM analysis, sandboxing) and possibly commercial support contracts with integrators.

Regulators will focus less on perfect contracts and more on whether you have a coherent rationale for how contractual and technical controls together achieve an adequate level of risk reduction.

8. Example: Supplier Risk Scoring Pseudocode

Illustrative scoring logic (for criticality classification)

Below is language‑agnostic pseudocode showing how you might encode a simple supplier risk scoring model. This is not mandated by NIS2, but demonstrates how to make your approach systematic and explainable.

```pseudo

Inputs (each on a scale, e.g., 0–5)

criticality: impact on essential/important services

data_sensitivity: confidentiality/integrity impact if data compromised

access_level: technical access (none, user, admin, OT remote)

concentration: extent to which many critical processes depend on this supplier

jurisdiction_risk: legal/geo-political risk of supplier locations

function calculatesupplierrisk(criticality, datasensitivity, accesslevel, concentration, jurisdiction_risk):

Weight factors according to your context and risk appetite

weight_criticality = 0.30

weightdatasensitivity = 0.20

weightaccesslevel = 0.25

weight_concentration = 0.15

weight_jurisdiction = 0.10

score = (criticality * weight_criticality) +

(datasensitivity * weightdata_sensitivity) +

(accesslevel * weightaccess_level) +

(concentration * weight_concentration) +

(jurisdictionrisk* weightjurisdiction)

Map numeric score to tiers used in your TPRM process

if score >= 4.0:

return "Tier 1 - Critical"

else if score >= 2.5:

return "Tier 2 - Important"

else:

return "Tier 3 - Non-critical"

Example usage

suppliertier = calculatesupplier_risk(

criticality = 5, # supports essential service delivery

data_sensitivity = 4, # processes operational data

access_level = 5, # remote admin access to OT

concentration = 4, # few alternative providers

jurisdiction_risk= 2 # moderate geo-legal risk

)

print(supplier_tier) # Expected: "Tier 1 - Critical"

```

In practice, you would:

• Calibrate weights and thresholds based on your sector and national guidance.
• Use this score to trigger different control sets (e.g., which clauses are mandatory, how often to reassess).

9. Monitoring Multi‑Tier Supply Chains: Scenario Analysis

Scenario: Fourth‑party outage in a SaaS dependency

You use a SaaS platform for real‑time monitoring of water treatment facilities (you are an essential entity). The SaaS provider relies on a third‑party cloud database service (a 4th‑party from your perspective).

A major outage at the database provider:

• Disrupts the SaaS provider’s service for 12 hours.
• Degrades your visibility into water treatment operations.

Questions to analyze (write down brief bullet answers):

1. Visibility

• How would you even know that the root cause is a 4th‑party outage and not your own systems?
• What contractual or technical mechanisms give you this visibility (e.g., incident reports, status pages, logging)?

1. NIS2 incident thresholds

• Could this outage constitute a significant incident under NIS2 for you (e.g., disruption of essential services, potential risk to public health)? Why or why not?
• What additional facts would you need to decide whether to notify the competent authority/CSIRT?

1. Controls and improvements

• Which upstream clauses in your contract with the SaaS provider could mitigate this risk (e.g., sub‑processor transparency, redundancy requirements)?
• What technical controls could you implement on your side (e.g., local buffering, fallback manual procedures)?

1. Regulatory defensibility

• If a regulator asks, “How did you manage the risk of this multi‑tier dependency?”, what evidence would you present (risk assessments, architectural diagrams, contracts, test results)?

Use this scenario to stress‑test whether your current or hypothetical TPRM approach really reaches beyond direct suppliers, as implied by Art. 21(2)(d).

10. Key Term Review: Supply Chain under NIS2

Flip the cards to reinforce core terminology and concepts.