What Is Supply Chain Risk Management? A NIS2 Guide to Third-Party Cyber Risk

Alexandru Ana, Chief Executive Officer

A security incident does not always come through the front door.

It may enter through a compromised software update, an MSP administrator account or a cloud platform your organisation depends on every day.

Your own perimeter may be well protected. Your supplier’s may not be.

 

Supply chain risk management is the systematic process of identifying, assessing and managing cybersecurity risks created by suppliers, service providers and other third parties.

 

Under NIS2, essential and important entities must address these risks through appropriate and proportionate cybersecurity risk-management measures, including risks arising from relationships with direct suppliers and service providers.

This is not a one-off supplier questionnaire. It is a recurring process: mapping → assessment → verification → contracting → monitoring → reassessment

 

Why the supply chain has become an extended attack surface

Ten years ago, cybersecurity focused much more heavily on defending your own network. Today, most organisations depend on a large ecosystem of services they do not directly control.

Cloud platforms, SaaS applications, managed service providers, software vendors and outsourced infrastructure have become part of the organisation’s operational environment.

Each dependency can also become a potential path to systems, identities or data. ENISA’s 2025 Threat Landscape notes increased targeting of third-party providers and cyber dependencies, including supply-chain attacks.

Its 2025 NIS Investments study provides another useful signal: supply-chain attacks were the second most frequently cited future cybersecurity concern, identified by 47% of surveyed organisations.

 

Growing dependence on third-party services

The list of suppliers with cybersecurity relevance has expanded considerably.

It can include:

 

• • cloud and IaaS providers;

• • SaaS applications used across the organisation;

• • managed service providers (MSPs);

• • managed security service providers (MSSPs);

• • systems integrators;

• • software vendors;

• • backup providers;

• • identity-management services;

• • OT and IoT suppliers;

• • hosting and data-centre providers;

• • business-critical outsourced platforms.

Cloud dependence is no longer a niche scenario.

In 2025, 52.7% of EU enterprises used paid cloud computing services, although adoption still varied considerably between Member States.

The practical point is not that cloud is inherently more risky. It is that more infrastructure, data and operational dependencies now sit outside the organisation’s direct control.

 

Direct supplier risk vs inherited supply-chain risk

There is an important distinction between the risk created by a direct supplier and the risk you inherit through that supplier.

Direct supplier risk comes from the organisation you have contracted.

You know who they are. You know what service they provide. You can usually assess their access and discuss controls with them.

Inherited or nth-party risk comes from the suppliers, platforms and subcontractors your supplier depends on.

You can therefore be affected by an incident at an organisation with which you have no direct contractual relationship.

For example:

Your MSP uses a remote monitoring platform. That platform is compromised. The attack reaches your environment through your MSP. You may not even have known that the underlying platform was part of the service.

 

Why securing your own infrastructure is not enough

An organisation can have strong internal controls and still remain exposed through third parties.

The weak point may not be inside your network. It may belong to someone who has the keys to it.

Examples include:

 

• • an MSP administrator account with broad privileges;

• • an API integration that remains active after it is no longer needed;

• • a compromised software component inside an application;

• • a critical cloud service becoming unavailable;

• • an unmanaged subcontractor;

• • a third-party remote-access tool;

• • unsupported software embedded in a supplier’s product.

This is why supplier risk is no longer something to review only during procurement. It is part of the organisation’s cybersecurity posture.

Interconnected IT supplier network, with cloud providers, software vendors, and MSPs linked through security relationships.

 

What does NIS2 require for supply chain security?

NIS2 explicitly includes supply chain security among the cybersecurity risk-management measures covered by Article 21.

Article 21(2)(d) refers specifically to security-related aspects of relationships between an entity and its direct suppliers or service providers.

Article 21 also requires organisations, when determining appropriate supply-chain measures, to consider factors such as:

 

• • vulnerabilities specific to each direct supplier or service provider;

• • the overall quality and resilience of products and services;

• • suppliers’ cybersecurity practices;

• • secure development procedures;

• • relevant coordinated assessments of critical supply chains. Eur-Lex

 

Proportionate does not mean optional

NIS2 requires measures to be appropriate and proportionate. That does not mean every supplier receives minimal scrutiny. It means the level of scrutiny should reflect the risk.

Useful factors include:

 

• • potential business impact;

• • supplier access to systems;

• • supplier access to sensitive data;

• • criticality of the service;

• • operational dependency;

• • availability of alternatives;

• • difficulty and time required to replace the supplier.

An office-supplies vendor and an MSP with domain-administrator access should not go through the same assessment process.

The first may require basic checks. The second deserves a far more detailed and documented assessment.

 

NIS2 requirements across Europe

The NIS2 Directive establishes the EU-level framework, but organisations also need to comply with the national law through which NIS2 has been transposed in the Member State relevant to them.

Supervisory procedures, evidence requirements, notification mechanisms and enforcement processes can therefore differ by jurisdiction.

For some categories of digital-sector entities, Commission Implementing Regulation (EU) 2024/2690 provides more detailed requirements.

Its supply-chain provisions include establishing and applying a supply-chain security policy and defining criteria for selecting and contracting suppliers and service providers.

The regulation applies to specific categories, including certain cloud, data-centre, CDN, MSP, MSSP, DNS, trust-service and online-platform providers; it should not be assumed to apply identically to every NIS2 entity.

For concrete legal obligations, always check the applicable national legislation and sector-specific rules.

 

Stage 1: Map critical suppliers and dependencies

You cannot protect what you do not know exists. The first stage is not particularly technical. It is inventory. And organisations often underestimate it because it looks like administrative work.

A supplier register tells you who the supplier is. A dependency map tells you what happens to your organisation if that supplier fails. You need both.

A dependency map shows what happens if a supplier can no longer provide the service, not just who the supplier is.

 

Build an inventory of the third-party ecosystem

The inventory should go beyond obvious procurement relationships.

Include organisations that:

 

• • access your data;

• • administer or configure systems;

• • support business-critical processes;

• • provide components embedded in your software;

• • perform maintenance or support with access to your environment;

• • provide infrastructure required for service continuity.

 

How do you identify critical suppliers?

From a list of dozens or hundreds of vendors, only a subset may be genuinely critical.

Useful criteria include:

 

• • access to sensitive information;

• • privileged access to systems;

• • degree of technical integration;

• • operational dependency;

• • absence of a viable alternative;

• • replacement time;

• • impact on continuity if the service becomes unavailable.

 

Map data flows and access paths

For every relevant supplier, document how they actually connect to the organisation.

A practical register might include:

 

• • systems accessed;

• • applications connected;

• • data received;

• • data transmitted;

• • privileged accounts;

• • API integrations;

• • data location;

• • subcontractors;

• • dependent business processes.

This often gives you more useful information than a supplier security policy on its own.

 

Supplier register or dependency map?

The difference matters. A supplier register tells you: Who do we buy from? A dependency map tells you: What breaks if they stop operating? The first supports administration. The second supports resilience.

 

Why static spreadsheets age quickly

A supplier register becomes less useful the moment reality moves faster than the spreadsheet. New vendors appear. Contracts change. Access is expanded. Subcontractors change. Architectures evolve. Services reach end of support. Incidents happen.

A useful register therefore needs an owner and a process for keeping it current whenever relevant changes occur.

 

Stage 2: Assess supplier risk proportionate to impact

Once the ecosystem is mapped, the next question is how much attention each supplier deserves. One of the most inefficient approaches is treating every supplier the same.

 

Why every supplier should not receive the same assessment

A uniform questionnaire may look fair on paper. Operationally, it creates noise. You send the same 80 questions to a courier and to a cloud provider. The courier spends time answering irrelevant questions. The cloud provider may already have extensive standard assurance documentation.

Meanwhile, your security team spends the same effort on low-impact suppliers as on suppliers that could shut down a critical service. Supplier assessment should follow risk.

 

Supplier tiering: three practical levels

The classification does not need to become unnecessarily complex.

For many organisations, three levels are enough.

Tier	Risk profile	Typical characteristics
1. Critical	High	Privileged access, sensitive data, OT/SCADA, critical cloud services, difficult to replace
2. Medium-high	Moderate	Important service, limited access, operational data, meaningful impact but alternatives exist
3. Standard	Low	Minimal access, limited data sensitivity, low operational impact, relatively easy to replace

The purpose is not to produce another label. The tier should determine what happens next:

 

• • assessment depth;

• • evidence required;

• • review frequency;

• • contractual controls;

• • approval level;

• • remediation expectations.

 

Impact and likelihood

Criticality tells you how severe the impact could be. Likelihood helps estimate how plausible the event is. Combining the two produces a more useful decision model.

A risk matrix can link: impact + likelihood → assessment type → reassessment frequency → owner → treatment

That turns judgement into a repeatable process.

The impact-likelihood matrix links each supplier to a specific risk treatment measure and a clearly assigned owner.

 

What indicators belong in a supplier-risk assessment?

A supplier score should not come from one question.

Useful inputs can include:

 

• • business-continuity impact;

• • business impact analysis (BIA);

• • data sensitivity;

• • level of technical access;

• • dependency on the supplier;

• • substitutability;

• • concentration risk;

• • supplier security maturity;

• • incident history;

• • reliance on subcontractors.

A score without a treatment plan, owner and deadline remains a number in a spreadsheet. It does not reduce risk.

 

Five due-diligence dimensions from NIST SP 1326

NIST’s final SP 1326: Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide, published in July 2026, provides a useful structure for ICT supplier due diligence.

It identifies five components:

 

1. 1. Foreign Ownership, Control or Influence (FOCI)

1. 1. Provenance

1. 1. Resilience

1. 1. Foundational Cyber Practices

1. 1. Supply Chain Tiers

These dimensions do not replace your own risk model. They provide a useful way to structure the questions behind it.

 

Stage 3: Security checks, due diligence and evidence

Supplier classification tells you where deeper verification is justified. This stage is about performing that verification without turning due diligence into a ritual.

 

Use questionnaires that match the supplier profile

A cloud provider, MSP, software vendor and logistics company should not receive exactly the same security questionnaire.

For example:

A cloud provider may need to explain tenant separation. That question may be irrelevant to a physical-services supplier.

The questionnaire should reflect the risk introduced by that supplier, not simply reproduce a universal template.

 

What should you ask an MSP or cloud provider?

For providers with privileged or critical access, useful questions include:

 

• • Who can obtain administrative access to our environment?

• • How is privileged access controlled and monitored?

• • How are customer environments separated?

• • How do you detect and manage incidents?

• • How quickly will you notify us?

• • Which subcontractors support the service?

• • How are backups and disaster recovery handled?

• • How can the service be terminated?

• • How do we retrieve our data?

• • How is access revoked when the relationship ends?

 

Supplier claims vs supplier evidence

A questionnaire response is not the same thing as evidence. It helps to think of assurance as a scale. A supplier response is a statement. A policy describes intent. A certification provides an assurance signal. An independent audit report provides third-party findings. A technical test provides verification.

Evidence showing remediation demonstrates that an identified issue was actually addressed.

For critical suppliers, you generally want more evidence towards the verification end of that spectrum.

 

Certifications and independent reports

Certifications are useful, but they are not interchangeable. They also do not automatically cover the exact service you are purchasing.

Examples that may be relevant include:

 

• • ISO/IEC 27001;

• • SOC 2 reports;

• • penetration-test reports;

• • external audit reports;

• • internal control reports;

• • external attack-surface assessments.

Always check scope. An ISO 27001 certificate covering a business unit unrelated to the service you use does not provide the assurance it may initially appear to provide.

 

Software suppliers, secure development and open source

Software vendors require a different type of due diligence.

Relevant areas include:

 

• • code provenance;

• • secure development lifecycle;

• • third-party components;

• • vulnerability management;

• • patching and update policies;

• • software bills of materials (SBOMs);

• • end-of-life and unsupported components.

The issue is not simply whether the supplier writes secure code. It is whether they understand and manage the components their software depends on.

 

External ratings do not replace internal analysis

Cyber ratings, external attack-surface monitoring and vulnerability intelligence can be useful. They tell you something about how the supplier looks from the outside.

They do not tell you:

 

• • which of your systems the supplier accesses;

• • which data it handles;

• • what your contract says;

• • how responsibility is divided;

• • what happens to your business if the supplier fails.

Use external signals as one input. Do not confuse them with a complete supplier-risk assessment.

 

Stage 4: Contractual security requirements and resilience

Pre-contract due diligence matters. But the contract is what remains when something goes wrong. This is where security expectations become defined obligations.

 

Security clauses and SLAs

Depending on supplier risk and applicable law, contractual controls may cover:

 

• • technical and organisational security requirements;

• • incident notification;

• • cooperation during investigations;

• • access to assurance documentation;

• • audit rights where appropriate;

• • vulnerability management;

• • security requirements for supplier personnel;

• • business continuity;

• • disaster recovery;

• • data portability;

• • secure deletion or return of data when the contract ends;

• • requirements relating to subcontractors.

For organisations covered by Implementing Regulation (EU) 2024/2690, the regulation goes further by defining specific supply-chain security expectations for contracts with suppliers and service providers.

 

Incident notification through the supply chain

If a critical supplier tells you about an incident two weeks after it happened, the information may arrive too late to support your own response.

The supplier needs to notify you quickly enough for your organisation to:

 

• • assess exposure;

• • investigate affected systems;

• • activate business-continuity measures;

• • preserve evidence;

• • make required internal decisions;

• • meet any applicable notification obligations.

One important distinction: your supplier does not automatically have the same statutory reporting deadline that applies to your organisation.

The supplier-to-customer notification requirement therefore needs to be addressed contractually where appropriate.

 

Define the shared-responsibility model

Cloud and managed-service environments regularly create ambiguity over ownership. A simple responsibility matrix helps remove it.

Activity	Typical ownership
Configuration of security controls	Supplier, with internal validation
Approval of access	Organisation
Activity monitoring	Shared according to SLA
Evidence retention	Both parties
Incident management	Supplier, with customer notification
Access revocation	Organisation
Recovery testing	Supplier, reported to customer
Approval of exceptions	Organisation

This is only an example. The actual division needs to reflect the architecture and contract.

 

Subcontractors and nth-party risk

Your suppliers have suppliers. And those suppliers may have suppliers of their own. This is nth-party risk. You cannot realistically audit every organisation in an extended global supply chain. You can, however, require your direct supplier to manage its own dependencies appropriately.

Depending on the relationship, contracts may address:

 

• • approval or disclosure of relevant subcontractors;

• • notification of material changes;

• • equivalent security obligations flowing down the chain;

• • access to relevant assurance information;

• • procedures for objecting to subcontractor changes;

• • incident-notification flow.

 

Hyperscaler vs local supplier

The contractual reality is different when dealing with a global hyperscaler and a smaller supplier. With a large platform, contractual conditions are often highly standardised and direct audit access may be unrealistic.

With a smaller provider, there may be considerably more room to negotiate:

 

• • audit rights;

• • notification periods;

• • specific security requirements;

• • tailored SLAs.

Where direct verification is impractical, assurance may rely more heavily on recognised certifications, independent reports, contractual commitments and other compensating measures.

 

Stage 5: Continuous monitoring, reassessment and exit planning

A supplier assessed two years ago may be a very different organisation today.

It may have:

 

• • been acquired;

• • changed subcontractors;

• • suffered a breach;

• • moved infrastructure;

• • expanded its access;

• • introduced new technology;

• • changed its financial position.

Supplier assessment therefore needs a lifecycle.

Continuous monitoring flags the risk; periodic reassessment confirms it and triggers action.

 

Continuous monitoring vs point-in-time assessment

A point-in-time assessment gives you a snapshot. Continuous monitoring looks for changes between assessments.

Useful signals can include:

 

• • expiring assurance documents;

• • newly disclosed vulnerabilities;

• • subcontractor changes;

• • public security incidents;

• • material infrastructure changes;

• • service changes;

• • unsupported products;

• • concerning financial developments.

An automated risk signal is not a final conclusion. It tells you where to investigate.

 

What should happen when a critical supplier is compromised?

When a critical provider experiences a breach, sequence matters.

A practical response flow can include:

 

1. 1. contact the supplier and request incident details;

1. 1. determine your own exposure;

1. 1. restrict supplier access if necessary;

1. 1. inspect dependent systems;

1. 1. activate continuity arrangements where required;

1. 1. preserve evidence;

1. 1. notify relevant internal stakeholders;

1. 1. perform a post-incident review;

1. 1. reassess the supplier and the relationship.

The exact process should already exist before the incident occurs.

 

What should trigger supplier reassessment?

Reassessment should not depend only on a calendar.

Useful triggers include:

 

• • security incident;

• • new subcontractor;

• • additional access;

• • acquisition or ownership change;

• • major contractual change;

• • architecture change;

• • severe vulnerability;

• • service expansion;

• • contract renewal.

Each can materially change the risk profile.

 

Exit planning and vendor lock-in

No supplier relationship lasts forever.

A practical exit plan should address:

 

• • data export;

• • data format;

• • migration timeline;

• • supplier transition support;

• • access revocation;

• • backup handling;

• • secure deletion;

• • alternative provider testing;

• • realistic migration cost.

The operational question is straightforward:

 

How difficult would it be to replace this supplier without disrupting the business?

If nobody knows the answer, the dependency itself deserves attention.

 

KPIs and KRIs for supplier risk management

Without indicators, it is difficult to know whether the programme is improving.

Useful metrics may include:

 

• • percentage of critical suppliers assessed;

• • current vs expired assurance evidence;

• • open supplier-security findings;

• • average remediation time;

• • suppliers without an exit plan;

• • supplier incident-notification time;

• • known subcontractors that have not yet been assessed.

Do not collect metrics simply because they are easy to count. Track the ones that help someone make a decision.

 

How to implement a repeatable supply chain risk management programme

Taken together, the stages above can look extensive. They become manageable when treated as a repeatable cycle.

A practical SCRM lifecycle is:

 

1. 1. inventory suppliers;

1. 1. map dependencies;

1. 1. classify by impact;

1. 1. perform due diligence proportionate to risk;

1. 1. embed requirements in contracts;

1. 1. monitor and reassess.

 

Who owns supply chain risk management?

SCRM is not exclusively an IT responsibility.

Depending on the organisation, it can involve:

 

• • cybersecurity;

• • IT;

• • procurement;

• • legal;

• • compliance;

• • risk;

• • business process owners;

• • senior management.

If responsibility is spread across every department without a defined owner, the process usually becomes fragmented. Ownership needs to be explicit.

 

Create a single source of truth

Supplier information spread across emails, spreadsheets, folders and security tools becomes difficult to maintain.

Relevant information should be accessible through a controlled and current system, including:

 

• • suppliers;

• • dependencies;

• • risks;

• • contracts;

• • evidence;

• • incidents;

• • remediation actions;

• • deadlines;

• • exit plans.

When an auditor, regulator or customer asks for supporting evidence, retrieving it should not become a multi-day investigation.

 

How Security OptiApp supports NIS2 supply chain risk management

This is where a platform such as Security OptiApp can support the process.

Security OptiApp centralises technical security posture and compliance documentation in one workspace. The platform can maintain evidence libraries, risk and incident registers, remediation plans, supply-chain security documentation and questionnaires received from auditors or customers. Findings can also be mapped to relevant NIS2 measures, reducing the manual work involved in correlating technical issues, documentation and evidence.

For supplier-risk management, this helps create a common place for information that would otherwise be spread across different teams and systems.

There is an important limitation to state clearly:

Security OptiApp does not automatically assess every external supplier and does not replace supplier due diligence, an audit, certification or an official NIS2 assessment.

 

Its role is to help the organisation maintain the information behind its own security and compliance posture: evidence, risks, incidents, remediation and relevant documentation.

See how Security OptiApp can support your NIS2 readiness and evidence management.

 

What a mature supplier-risk process should achieve

Supply chain risk management is not a project with a fixed end date.

It requires:

 

• • clear ownership;

• • current supplier information;

• • risk-based assessment;

• • relevant evidence;

• • appropriate contractual controls;

• • periodic reassessment;

• • remediation tracking;

• • continuity plans;

• • exit plans.

The objective is broader than passing an audit.

A mature supplier-risk programme helps the organisation maintain critical services and reduce the impact when a supplier becomes unavailable, compromised or no longer meets the required level of security.

 

Frequently asked questions about NIS2 supply chain risk management

What is supply chain risk management?

Supply chain risk management is the continuous process of identifying, assessing, treating and monitoring risks created by suppliers, service providers and their dependencies.

In cybersecurity, it covers the full lifecycle from supplier mapping and due diligence to contracting, monitoring and reassessment.

Does NIS2 require supply chain security?

Yes. Article 21(2)(d) of NIS2 explicitly includes supply chain security, including security-related aspects of relationships between entities and their direct suppliers or service providers.

What is a critical supplier?

A critical supplier is typically one whose failure or compromise could cause significant operational or security impact.

Indicators may include privileged access, sensitive data, technical integration, critical business services and difficulty of replacement.

What is nth-party risk?

Nth-party risk is the risk created by suppliers and subcontractors further down your supplier’s own supply chain.

Your organisation may therefore be affected by a breach at a company with which you have no direct contract.

Are supplier certifications enough for NIS2?

Not on their own. Certifications such as ISO 27001 and assurance reports such as SOC 2 can provide useful evidence, but organisations should assess whether the scope is relevant to the actual product or service and consider supplier-specific risk.

How should an MSP or cloud provider be assessed?

The assessment should reflect the service and risk.

Typical areas include privileged access, account monitoring, customer separation, incident management, subcontractors, continuity and disaster recovery, data handling and termination procedures.

What if a large cloud provider does not allow direct audits?

Organisations may need to rely on alternative assurance mechanisms such as recognised certifications, independent audit reports, published control documentation and contractual commitments. The suitability of those measures depends on the risk and applicable regulatory requirements.

Does supply chain risk management replace the NIS2 assessment?

No. Supply chain security is one component of the broader cybersecurity risk-management framework required by NIS2. It does not replace the organisation’s wider NIS2 obligations or national compliance processes.

 

About Optimizor

Optimizor provides IT managed services and cybersecurity support for organisations operating hybrid IT environments, with expertise across security, NIS2 readiness and the Microsoft ecosystem. Optimizor is the developer of Security OptiApp and a provider of managed IT services in the EU. The analysis in this article is based on primary public sources and the team’s operational experience. Legal obligations should always be checked against the applicable national NIS2 transposition law, sector-specific requirements and current regulatory guidance.

 

 

Sources

 

1. 1. Directive (EU) 2022/2555 (NIS2), Article 21 – European Parliament and Council. Eur-Lex
   2. Commission Implementing Regulation (EU) 2024/2690 – detailed cybersecurity requirements for covered digital-sector entities. Eur-Lex
   3. Eurostat – Cloud computing in enterprises, 2025. European Commission
   4. ENISA Threat Landscape 2025. ENISA
   5. ENISA NIS Investments 2025 – third-party and supply-chain security. ENISA
   6. NIST SP 1326 – Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide, final 2026.

1.  

1.  

1.  

1.  

1.