CONTROL LAYER NIS2 Dependencies DORA Oversight ISO Controls NIST Governance EVIDENCE • MONITORING • RESPONSE

Management Summary

Regulators no longer treat supply chain security as optional good practice. It is increasingly an explicit legal and supervisory expectation. The common theme across NIS2, DORA, ISO 27001:2022, and NIST CSF 2.0 is simple: organizations must know their dependencies, manage supplier risk proportionately, maintain evidence, and be able to respond quickly when third-party incidents occur.

For security leaders, the practical implication is that supply chain security now sits at the intersection of legal compliance, operational resilience, and audit readiness. The four frameworks differ in scope and enforcement mechanism, but they converge on the same five expectations:

  1. Know your dependencies
  2. Apply risk-based due diligence and contractual controls
  3. Monitor suppliers continuously, not annually
  4. Control and segment third-party access
  5. Prepare to detect, report, and contain supply chain incidents fast

The sections below explain each framework's specific requirements, what they mean in practice, and how to implement them — including sample solutions, evidence expectations, and ownership recommendations.

Executive lens

The most efficient path is not to build four separate compliance workstreams. It is to build one integrated supply chain risk program and map its evidence to each framework.

1. NIS2 Makes Supply Chain Security a Legal Obligation

The big picture

NIS2 explicitly requires entities to address supply chain security, including supplier relationships, supplier-specific vulnerabilities, cybersecurity practices, and secure development aspects where relevant. It also increases pressure through strict incident reporting timelines.

NIS2 Article 21(2)(d) explicitly mandates “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” Article 21(3) requires entities to consider vulnerabilities specific to each supplier, their cybersecurity practices, and secure development procedures. Non-compliance carries fines up to €10 million or 2% of worldwide turnover for essential entities and €7 million or 1.4% for important entities.

NIS2’s three-stage incident reporting under Article 23 creates urgency for supply chain breaches:

  1. 24-hour early warning — must flag potential cross-border impact
  2. 72-hour incident notification — severity assessment, indicators of compromise, actions taken
  3. 1-month final report — root cause analysis, complete chronology, lessons learned

As of 2025, the European Commission had sent reasoned opinions to 19 of 27 Member States for failing to complete transposition by the October 2024 deadline.

Key references:

What this means in practice

A NIS2-covered organization should be able to demonstrate that it:

Sample solution to fulfill the requirement

Practical implementation model

  1. Create a critical supplier inventory — Identify suppliers supporting critical or important services, including IT, cloud, MSPs, SaaS, software vendors, and key sub-processors.
  2. Risk-tier the supplier base — Use criteria such as business criticality, privileged access, data sensitivity, concentration risk, and recovery dependency.
  3. Introduce minimum security requirements — MFA, incident notification clauses, vulnerability management expectations, encryption, logging, and access control standards.
  4. Establish supplier monitoring — Annual reassessment for lower-tier suppliers; continuous monitoring and quarterly review for high-risk suppliers.
  5. Integrate suppliers into incident response — Define points of contact, notification paths, evidence-sharing expectations, and escalation timelines aligned to 24h / 72h / 1 month reporting.
  6. Maintain evidence — Keep risk assessments, contractual clauses, monitoring outputs, action plans, and incident logs.

Example artifacts / evidence

Suggested owners

2. DORA Mandates Oversight of ICT Third-Party Risk

The big picture

DORA expects financial entities to maintain a Register of Information, conduct pre-contract due diligence, assess ICT concentration risk, and ensure resilience in the use of ICT third-party services.

The Digital Operational Resilience Act, directly applicable since January 17, 2025, requires financial entities under Article 28(3) to maintain a comprehensive Register of Information documenting all contractual arrangements with ICT third-party service providers — at entity, sub-consolidated, and consolidated levels. First submissions were due April 30, 2025. Article 28(4) requires pre-contractual due diligence; Article 29 mandates ICT concentration risk assessment; Article 28(5) requires use of the most up-to-date and highest quality information security standards for critical functions.

DORA’s Critical Third-Party Provider oversight framework (Articles 31–44) empowers European Supervisory Authorities — EBA, EIOPA, and ESMA — to designate, investigate, and inspect systemically important ICT providers.

Key references:

What this means in practice

For a financial entity, this is not just a vendor register exercise. It is a control framework around:

Sample solution to fulfill the requirement

Practical implementation model

  1. Build a DORA-aligned Register of Information — Centralize all ICT third-party arrangements, including service descriptions, supported functions, subcontractors, geographic delivery, data locations, contract terms, exit dependencies, and criticality.
  2. Perform pre-contract due diligence — Review security posture, resilience controls, certifications, incident history, financial stability, subcontracting model, and dependency on fourth parties.
  3. Assess concentration risk — Identify where multiple critical services rely on the same cloud provider, software vendor, telecom provider, or data transfer platform.
  4. Strengthen contractual controls — Include audit rights, notification timelines, security requirements, testing expectations, data access provisions, termination support, and exit assistance.
  5. Link monitoring to governance — Review critical ICT providers at least quarterly, escalate material issues to management, and ensure the Register stays current.
  6. Test operational resilience — Include third-party failure and outage scenarios in business continuity and incident response exercises.

Example artifacts / evidence

Suggested owners

3. ISO 27001:2022 Annex A Provides the Implementation Blueprint

The big picture

ISO 27001:2022 offers the clearest implementation controls for supplier security through four dedicated controls:

These four controls directly address supply chain security:

Key references:

What this means in practice

ISO turns the general expectation into a manageable control set. It helps organizations translate supply chain risk into policies, contracts, reviews, technical controls, and auditable evidence.

Sample solutions by control

A.5.19 — Information security in supplier relationships

Sample solution: Create a supplier security policy that requires supplier onboarding due diligence, classification by criticality, and baseline controls depending on supplier tier.

Evidence:

A.5.20 — Security in supplier agreements

Sample solution: Use a standard contract appendix covering security controls, incident notification, right to audit, data handling, subcontracting restrictions, business continuity, and minimum authentication requirements.

Evidence:

A.5.21 — Managing information security in the ICT supply chain

Sample solution: For software and ICT suppliers, require secure development evidence, SBOM where feasible, vulnerability disclosure expectations, sub-processor transparency, and verification of software or artifact integrity for critical tools.

Evidence:

A.5.22 — Monitoring, review and change management

Sample solution: Implement periodic reviews for all critical suppliers, trigger ad hoc reassessment on incidents or material changes, and track remediation through a formal action register.

Evidence:

Suggested owners

4. NIST CSF 2.0 Makes Supply Chain Risk a Governance Function

The big picture

NIST CSF 2.0 moves supply chain risk into the GV.SC category, which is significant because it frames supply chain security as a governance and risk management responsibility, not only a technical matter.

The GV.SC (Cybersecurity Supply Chain Risk Management) category is the most detailed in the framework, with 10 subcategories spanning program establishment, supplier criticality prioritization, contractual requirements integration, ongoing monitoring, incident planning with suppliers, and post-termination provisions. NIST SP 800-161r1 provides a much deeper C-SCRM model mapped to NIST 800-53 Rev. 5 across 20 control families.

Key references:

What this means in practice

Organizations should be able to show that supply chain risk management is:

Sample solution to fulfill the requirement

Practical implementation model aligned to GV.SC

Minimal viable implementation

  1. Issue a C-SCRM policy,
  2. define supplier tiers,
  3. assign accountable owners,
  4. implement third-party assessment and continuous monitoring,
  5. integrate suppliers into incident response and crisis management,
  6. measure performance through board-facing KPIs.

Example KPIs

Suggested owners

5. How the Frameworks Map to Real Supply Chain Incidents

The frameworks become easier to operationalize when they are tied to real incidents. The table below maps recurring failure patterns from the previous article to the most relevant control expectations.

Incident Control failure Applicable control Reference
SolarWinds Build-process integrity not verified ISO A.5.21, NIST GV.SC-07 A.5.21 guide
Kaseya Unpatched critical RMM; no concentration risk assessment ISO A.5.22, DORA Art. 29 DORA Art. 29
MOVEit No register of critical shared dependencies DORA Art. 28(3), NIS2 Art. 21 DORA Art. 28
Change Healthcare No MFA; poor segmentation; concentration risk DORA Art. 29, ISO A.5.19, NIS2 Art. 23 NIS2 Art. 23
XZ Utils No open-source component criticality assessment NIS2 Art. 22, ISO A.5.21 NIS2 Art. 22
Polyfill.io No SRI on third-party scripts ISO A.5.21 (integrity verification) MDN SRI
tj-actions Mutable CI/CD dependency tags NIST GV.SC-07, ISO A.5.21 MITRE T1677

Related article: The Supply Chain Is Now the Biggest Cyber Threat

Executive Takeaway

The four frameworks are not competing standards — they are converging expectations. Whether an organization is subject to NIS2, DORA, ISO 27001, NIST CSF 2.0, or a combination, the required capabilities are the same: supplier visibility, risk-based controls, contractual governance, continuous monitoring, and incident readiness.

The most efficient approach is to build one integrated supply chain risk program and map it to each framework’s specific evidence requirements, rather than maintaining parallel compliance silos.

In practice, that means:

  1. one supplier inventory,
  2. one criticality and risk-tiering model,
  3. one contractual security baseline,
  4. one monitoring and reporting model,
  5. one cross-functional incident process that includes suppliers.

Organizations that build these capabilities well will not only improve compliance. They will also improve resilience, reduce blind spots, and be better positioned to defend their decisions when regulators, auditors, customers, or boards ask the same question: how well do you actually understand and control your dependencies?

Annex A

Suggested Evidence Pack for an Audit-Ready Program

For teams building a regulator-ready supply chain security capability, the following evidence pack is usually enough to satisfy most first-line, second-line, and audit-level questions:

Back to Writing