Supply Chain Security Under NIS2: Managing Third-Party Risk

Who should read this: Procurement officers, CISOs, risk managers, vendors, and anyone responsible for third-party management and supply chain risk.

The SolarWinds breach of 2020 taught a bitter lesson: an attacker who compromises a single software provider can infiltrate thousands of customers simultaneously. A trusted vendor becomes a trojan horse.

NIS2 responded by making supply chain security mandatory. Article 21(2)(d) requires every essential and important entity to implement "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers."

This is not a guideline or best practice. It is a regulatory obligation. This guide explains what it requires, how to build a vendor risk programme, and what to do about the risks you uncover.

What Is Supply Chain Security?

Supply chain security means managing the cybersecurity risk posed by your vendors, suppliers, and service providers.

Your vendors are part of your attack surface. If a vendor is compromised, your systems could be compromised. If a vendor's network connects to yours (for remote support, data sharing, etc.), an attacker who infiltrates the vendor could tunnel into your systems. If you integrate a vendor's software into your systems, vulnerabilities in that software become your problem.

NIS2 recognizes this and makes it your responsibility to manage vendor risk. You must:

Identify critical vendors and service providers whose failure or compromise would disrupt your services.

Assess their cybersecurity practices and maturity.

Set contractual security requirements.

Monitor their compliance over time.

Have contingency plans if they are compromised or become unavailable.

This is a significant expansion of cybersecurity responsibility. In the past, vendor security was often treated as optional. Under NIS2, it is mandatory.

Identifying Critical Suppliers

The first step is inventory: who are your vendors and service providers?

Create a vendor register that lists:

All external vendors and service providers (cloud providers, software vendors, outsourced IT providers, consultants, etc.).

The service or product they provide.

The criticality of that service or product to your operations (is it critical to service delivery, or is it peripheral?).

Whether they have access to your network or systems.

Whether they handle or process sensitive data.

Not all vendors are equally critical. A vendor who provides office supplies poses far less risk than a vendor who provides cloud services and handles customer data. Focus your assessment effort on critical vendors—those whose failure, unavailability, or compromise would disrupt your services or endanger data.

Article 21(3) specifies: "Member States shall ensure that, when considering which measures referred to in paragraph 2, point (d), of this Article are appropriate, entities take into account the vulnerabilities specific to each direct supplier and service provider..."

This means you must assess each critical supplier individually, not apply a one-size-fits-all approach. A small local consultant poses different risks than a global cloud provider. Your assessment and controls should reflect that difference.

Assessing Vendor Security

Once you have identified critical vendors, assess their cybersecurity practices. This typically involves:

Vendor Questionnaire

Create a security questionnaire to gather information about the vendor's practices. The questionnaire should cover:

Security governance: Does the vendor have a Chief Information Security Officer or equivalent? Do they have a cybersecurity policy?

Risk assessment: Do they conduct risk assessments? How often?

Incident response: Do they have an incident response capability? How quickly can they respond?

Business continuity: Do they have backup and disaster recovery capability? What is their recovery time objective?

Access control: How do they manage access to systems? Do they use multi-factor authentication?

Encryption: Do they encrypt data in transit and at rest?

Patch management: How quickly do they patch vulnerabilities?

Vendor management: Do they assess their own vendors? (This is the "nth party risk"—your vendor's vendors.)

Training and awareness: Do they conduct security training?

Audits and certifications: Do they have certifications (ISO 27001, SOC 2, etc.) or undergo regular audits?

Compliance: Do they comply with relevant regulations (GDPR, NIS2, PCI DSS, HIPAA, etc.)?

Use standard questionnaires where possible (the Shared Assessments Standard Information Gathering (SIG) questionnaire is widely used). Tailor the questionnaire to the vendor's role and the criticality of their services.

Audit or Assessment

For critical vendors, move beyond a questionnaire. Consider conducting or commissioning a security audit.

Options include:

Vendor self-assessment: The vendor conducts a self-assessment against a standard (e.g., ISO 27001) and provides a report.

Third-party audit: You hire an independent auditor to assess the vendor's security practices.

Penetration testing: For the most critical vendors, conduct a penetration test to identify exploitable vulnerabilities.

Vendor certification: Require the vendor to obtain a recognized certification (ISO 27001, SOC 2 Type II). This provides independent verification of their practices.

The depth of assessment should reflect criticality. A vendor providing basic services might undergo a questionnaire only. A cloud provider handling critical customer data should undergo a third-party audit and hold relevant certifications.

Product Security Assessment

For software vendors, assess the security of their products. This includes:

Code review: Request that the vendor's code be reviewed by an independent security firm (not required from all vendors, but appropriate for critical software).

Vulnerability history: Ask about past vulnerabilities in their products. How many? How severe? How quickly did they patch?

Secure development practices: Do they use secure coding standards, code review, and testing?

Vulnerability disclosure policy: Do they have a coordinated vulnerability disclosure policy? How do they handle researchers who discover vulnerabilities?

Supply chain security: Do they assess their own suppliers and subcontractors?

Contractual Controls

Your vendor contracts must spell out security requirements. Standard contracts often do not address security. You must add security clauses.

Your contract should require the vendor to:

Maintain a cybersecurity programme meeting certain standards (ISO 27001, NIST Cybersecurity Framework, or equivalent).

Notify you of significant security incidents affecting your data or systems within a defined timeframe (e.g., 24 hours).

Maintain confidentiality and not disclose your data or systems information to third parties without your written consent.

Implement multi-factor authentication for access to your systems and data.

Encrypt sensitive data in transit and at rest.

Conduct regular security assessments (penetration tests, vulnerability scans) and remediate findings.

Manage their own vendors and require them to meet equivalent security standards.

Maintain business continuity and disaster recovery capability with defined recovery time objectives.

Provide audit rights: you have the right to audit their security practices.

Allow you to terminate the contract if they suffer a material security incident or fail to meet security requirements.

Require liability insurance that covers security breaches.

These clauses should be part of your standard vendor contract template. When negotiating with a new vendor, security requirements should be negotiated alongside price and service level.

Ongoing Monitoring

Assessing a vendor once is not enough. Supply chain security is ongoing.

You should:

Monitor for security incidents: Track vendor incidents in the news, check if they are breached, monitor security bulletins for vulnerabilities in their products.

Conduct periodic re-assessments: At least annually, re-assess critical vendors using the same questionnaire or audit. Update your assessment based on new findings.

Review security patches: Stay informed about patches the vendor releases. Verify that your systems are patched promptly.

Monitor for changes: Does the vendor change ownership? Outsource critical functions? These changes could affect security.

Participate in vendor security briefings: Some vendors offer quarterly security updates for customers. Attend these to learn about recent threats and the vendor's response.

Re-negotiate contracts as needed: If a vendor is acquired, or if their security practices degrade, re-negotiate contract terms to address changed risk.

Coordinated Risk Assessments

Article 21(3) requires that you "take into account the results of the coordinated security risk assessments of critical supply chains carried out in accordance with Article 22(1)."

Article 22(1) authorizes the Cooperation Group (a coordination body of EU Member States) to conduct coordinated security risk assessments of specific critical ICT services, systems, or products supply chains. These assessments are carried out at the EU level to assess risks to critical components of digital infrastructure.

When the Cooperation Group publishes a coordinated risk assessment of a critical supply chain (e.g., cloud computing services, DNS services, semiconductor supply chain), you must consider this assessment when managing your own vendor risk. If the assessment identifies vulnerabilities in a supply chain your vendors rely on, you should factor this into your vendor management decisions.

Monitor for Cooperation Group assessments relevant to your vendors and incorporate findings into your risk management.

Vendor Risk in Different Contexts

Supply chain risk varies by vendor type. Here are key considerations for different categories:

Cloud Service Providers

Your cloud provider has access to your data and systems. Critical controls include:

Service level agreements (SLAs) defining availability, recovery time objectives, and incident notification timelines.

Data protection clauses requiring encryption, access controls, and confidentiality.

Audit rights: you must be able to audit the provider's security controls.

Subprocessor requirements: the cloud provider must disclose and approve any subprocessors (vendors they use) and ensure they meet equivalent security standards.

Data retention and deletion: define how data is handled when the contract ends.

Software Vendors

Software you integrate into your systems becomes part of your security posture. Controls include:

Vulnerability disclosure and patching timelines: the vendor must disclose vulnerabilities and patch promptly.

Secure development practices: require the vendor to follow secure coding standards and conduct testing.

Software bill of materials (SBOM): require the vendor to provide a list of all open-source and third-party components in their software. This helps you identify vulnerabilities in dependencies.

License compliance: ensure the software is properly licensed and does not include unlicensed or stolen components.

Outsourced Services (IT Support, Security Operations, etc.)

If you outsource IT operations or security functions, your provider has elevated access and knowledge. Controls include:

Background checks on personnel with access to your systems.

Security clearances or equivalent vetting if handling sensitive data.

Non-disclosure agreements binding all personnel.

Separation of duties: limit the vendor's access to only what is needed for their function.

Continuous monitoring: log and monitor vendor access to your systems.

Regular audits to verify they are meeting obligations.

Hardware and Procurement Supply Chain

Physical components (servers, networking equipment, etc.) can be tampered with. Controls include:

Verification of authenticity: ensure hardware is genuine and not counterfeit or refurbished.

Supply chain verification: trace hardware from manufacturer to you to ensure it is not intercepted or modified.

Firmware verification: verify that firmware on devices has not been modified or contains backdoors.

For government entities or those handling highly sensitive data, this may involve specialized procurement processes or supply chain verification services.

Contingency Planning

You must have contingency plans if a critical vendor fails, is compromised, or becomes unavailable.

For each critical vendor, ask: what would happen if this vendor suddenly became unavailable? How would we maintain service?

Contingency plans might include:

Alternative vendors: maintain relationships with backup vendors who could take over if your primary vendor fails.

Hybrid arrangements: use multiple vendors for the same service, so no single vendor is a single point of failure.

In-house capability: develop in-house capability to provide a critical function if a vendor becomes unavailable (this requires more resources but provides maximum resilience).

Contractual requirements: require your vendor to maintain business continuity capability and define recovery time objectives.

Regular testing: test your contingency plans regularly. Can you actually switch to a backup vendor in the timeframe needed?

The goal is not to eliminate third-party risk--most modern organisations depend on vendors. Rather, the goal is to understand the risk and have plans to mitigate it.

Vendor Risk Governance

Build governance around vendor management:

Procurement review: before contracting with a new vendor, conduct a security assessment. Do not accept vendors who refuse to disclose security practices or allow audits.

Vendor risk committee: establish a committee to review vendor risk assessments, approve vendor relationships, and monitor vendor performance.

Vendor risk register: maintain a register of critical vendors, their risk rating, and any outstanding security issues.

Annual review: at least annually, review all critical vendor relationships. Are they meeting security requirements? Have new risks emerged?

Board visibility: escalate high-risk vendor relationships to the board or board committee for oversight.

The Vendor's Perspective

If you are a vendor, NIS2 affects you as well. Your customers will assess your security and impose contractual requirements. To compete effectively:

Develop a strong cybersecurity programme (ISO 27001 certification is a good baseline).

Conduct regular security assessments and be transparent about results.

Maintain a coordinated vulnerability disclosure policy.

Be prepared to answer security questionnaires and undergo audits.

Develop a vendor risk management programme for your own vendors.

Publish a security white paper or documentation describing your security practices.

Key Takeaways

- Supply chain security (Article 21(2)(d)) is now a mandatory regulatory obligation; you must identify critical vendors, assess their cybersecurity practices, set contractual requirements, and monitor compliance over time.

- Critical vendor assessment should be proportionate to criticality and risk; use security questionnaires for all vendors, conduct audits for critical vendors handling sensitive data or providing critical services, and require certifications (ISO 27001, SOC 2) where appropriate.

- Vendor contracts must include security clauses requiring the vendor to maintain a cybersecurity programme, notify you of incidents, implement multi-factor authentication and encryption, conduct assessments, manage their own vendors, maintain business continuity, and allow you to audit their practices.

- Ongoing monitoring is essential: track vendor incidents in the news, conduct annual re-assessments, monitor security patches, stay informed of changes to the vendor's practices or ownership, and re-negotiate contracts if risk changes.

- Coordinated risk assessments conducted by the Cooperation Group (EU level) of critical ICT supply chains should be monitored and incorporated into your vendor management decisions.

- Contingency planning requires identifying what would happen if a critical vendor failed, developing alternative vendor relationships or in-house capability, and regularly testing your ability to activate contingencies.